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

[Emma Humphries]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed W3C Charter: WebRTC Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  WebRTC Working Group
  https://www.w3.org/2018/04/webrtc-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2018Apr/0008.html

Mozilla has the opportunity to send comments or objections through
Friday, May 25.

The changes relative to the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2015%2F07%2Fwebrtc-charter.html=https%3A%2F%2Fwww.w3.org%2F2018%2F04%2Fwebrtc-charter.html

The groups work includes the WebRTC specification (real-time
communication between browsers) and a number of specifications
related to media capture and media streams, many of which we
implement.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-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

Proposed W3C Charter: Devices and Sensors Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Devices and Sensors Working Group
  https://w3c.github.io/dap-charter/DeviceAPICharter.html
  https://lists.w3.org/Archives/Public/public-new-work/2018Apr/0010.html

Mozilla has the opportunity to send comments or objections through
Friday, May 25.

The changes relative to the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F03%2Fdevice-sensors-wg-charter.html=https%3A%2F%2Fw3c.github.io%2Fdap-charter%2FDeviceAPICharter.html

This working group works on browser APIs for sensors such as battery
status, wake lock, proximity, ambient light, accelerometer,
gyroscope, magnetometer, orientation, and geolocation, and on a
generic sensor API on which many of them are based, and also
maintains existing work related to media capture (camera,
microphone, and from web pages) and the vibration API.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-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

Proposed W3C Charter: Distributed Tracing Working Group

[L. David Baron]

The W3C is proposing a charter for a new working group:

  Distributed Tracing Working Group
  https://www.w3.org/2018/04/distributed-tracing-wg-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2018Apr/0005.html

Mozilla has the opportunity to send comments or objections through
Friday, May 18.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-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

Proposed W3C Charter: Timed Text Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Timed Text Working Group
  https://www.w3.org/2018/04/proposed-tt-charter-2018.html
  https://lists.w3.org/Archives/Public/public-new-work/2018Apr/0003.html

Mozilla has the opportunity to send comments or objections through
Thursday, May 17.

The changes relative to the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F05%2Ftimed-text-charter.html=https%3A%2F%2Fwww.w3.org%2F2018%2F04%2Fproposed-tt-charter-2018.html

This working group is reponsible for both TTML (and XML-based and
XSL-FO-based format that we do not support) and WebVTT (an HTML- and
CSS-based format that we do support).

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-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: Firefox 60 Beta build error on ARM

[David Major]

This sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=1434589
which currently doesn't have a fix. You might be able to work around
it for now with --disable-webrtc.

On Wed, May 2, 2018 at 1:08 PM, Charles G Robertson
 wrote:
> Hi,
>
> I'm trying to build Firefox 60 Beta on Arm64 and seeing this error:
> ...
> g++: error: unrecognized command line option '-msse2'
> gmake[4]: *** [/home/abuild/rpmbuild/BUILD/mozilla/config/rules.mk:1049: 
> Unified_cpp_common_audio_sse2_gn0.o] Error 1
> gmake[3]:
>   *** [/home/abuild/rpmbuild/BUILD/mozilla/config/recurse.mk:73:
> media/webrtc/trunk/webrtc/common_audio/common_audio_sse2_gn/target]
> Error 2
> gmake[3]: *** Waiting for unfinished jobs
> ...
>
> Had no
> issue building Firefox 59 for Arm64 so something changed between 59 and 60. 
> Is there some configure option I
> should be enabling/disabling when building FF 60 on Arm?
>
> Thanks,
> Charles Robertson
> SUSE
>
> ___
> 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

Firefox 60 Beta build error on ARM

[Charles G Robertson]

Hi,

I'm trying to build Firefox 60 Beta on Arm64 and seeing this error:
...
g++: error: unrecognized command line option '-msse2'
gmake[4]: *** [/home/abuild/rpmbuild/BUILD/mozilla/config/rules.mk:1049: 
Unified_cpp_common_audio_sse2_gn0.o] Error 1
gmake[3]:
  *** [/home/abuild/rpmbuild/BUILD/mozilla/config/recurse.mk:73:  
media/webrtc/trunk/webrtc/common_audio/common_audio_sse2_gn/target]  
Error 2
gmake[3]: *** Waiting for unfinished jobs
...

Had no  
issue building Firefox 59 for Arm64 so something changed between 59 and 60. Is 
there some configure option I  
should be enabling/disabling when building FF 60 on Arm?

Thanks,
Charles Robertson
SUSE

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

Re: Intent to implement: AudioWorklet

[hongchan]

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

Re: Intent to implement: AudioWorklet

[Boris Zbarsky]

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

Maintenance work on perf-html.io, planned for May 3 at 8am PDT, small downtime planned

[Julien Wajsberg]

Hi,

Tomorrow we'll move perf-html.io to a new home.

As part of this switch we'll chance the DNS servers so that they point 
to the new hosting at netlify.com. This should be painless.


However as part of the process we also need to generate new TLS 
certificates, and we can do this only once the DNS switch is done. 
That's why we'll have a small downtime until the new certificates are 
set up.


In case of a bigger issue we'll rollback to the old hosting and postpone 
the switch.


Please follow Bug 1455605 to know more.

Have a nice day !
--
Julien

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

Re: Intent to implement: AudioWorklet

[Xidorn Quan]

On Wed, May 2, 2018, at 11:34 PM, Tom Ritter wrote:
> On Wed, May 2, 2018 at 5:11 AM, Robert O'Callahan  
> wrote:
> > On Wed, May 2, 2018 at 9:21 PM, Karl Tomlinson  wrote:
> >
> >> It seems that Chrome works around this by choosing to garbage
> >> collect input nodes even when their presence is specified to
> >> require (observable) AudioWorkletProcessor.process() calls.
> >> This garbage collection is performed in a way that causes the
> >> process() calls to be halted (which stops sound production), and
> >> so the AudioWorkletProcessor can subsequently also be garbage
> >> collected if there are no rooted references, as usual.
> >>
> >> Having the behavior of AudioWorkletProcess depend on whether or
> >> not the client maintains references to input nodes is not
> >> something I'd like to implement.  It would be comparable to an
> >> audio element stopping playback at a time when an implementation
> >> chooses to perform garbage collection after the client has removed
> >> its last reference.  It is contrary to [[TAG design principles]].
> >> The Chrome approach seems to be based on a different understanding
> >> of [[AudioNode Lifetime]].
> >>
> >
> > Making GC timing observable is a big, big problem. I hope you escalate this
> > aggressively with the Chrome team.
> 
> Hey Rob,
> 
> It's not difficult to force a GC in javascript, so I'm curious why
> making the duration of a GC observable is a problem?  Do you think you
> could unpack it for me?

The duration of GC being observable is not a problem. The problem is the 
timing, i.e. when GC is triggered. The main point is that, any accessible 
object should not have observable behavior difference regarding whether GC is 
triggered.

Having that observable is a problem because different implementations trigger 
GC at different time, and even a single implementation may choose to trigger GC 
at different time when they try to adopt some new optimization.

If an accessible object have different behavior depending on whether GC has 
been triggered, web content may start depending on the timing which is 
currently used by some implementation. That can later become a huge webcompat 
nightmare for everyone.

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

Re: Default Rust optimization level decreased from 2 to 1

[Julien Wajsberg]

Le 25/04/2018 à 18:26, Bobby Holley a écrit :

Could we instead have the profiler UI throw up a warning if the build was
not compiled with --enable-release?


I filed https://github.com/devtools-html/perf.html/issues/976 to discuss 
about it.

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

Re: Intent to implement: AudioWorklet

[Tom Ritter]

On Wed, May 2, 2018 at 5:11 AM, Robert O'Callahan  wrote:
> On Wed, May 2, 2018 at 9:21 PM, Karl Tomlinson  wrote:
>
>> It seems that Chrome works around this by choosing to garbage
>> collect input nodes even when their presence is specified to
>> require (observable) AudioWorkletProcessor.process() calls.
>> This garbage collection is performed in a way that causes the
>> process() calls to be halted (which stops sound production), and
>> so the AudioWorkletProcessor can subsequently also be garbage
>> collected if there are no rooted references, as usual.
>>
>> Having the behavior of AudioWorkletProcess depend on whether or
>> not the client maintains references to input nodes is not
>> something I'd like to implement.  It would be comparable to an
>> audio element stopping playback at a time when an implementation
>> chooses to perform garbage collection after the client has removed
>> its last reference.  It is contrary to [[TAG design principles]].
>> The Chrome approach seems to be based on a different understanding
>> of [[AudioNode Lifetime]].
>>
>
> Making GC timing observable is a big, big problem. I hope you escalate this
> aggressively with the Chrome team.

Hey Rob,

It's not difficult to force a GC in javascript, so I'm curious why
making the duration of a GC observable is a problem?  Do you think you
could unpack it for me?

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

Re: QA Firefox 62 feature testing pi-requests deadline is May 2

[Tom Grabowski]

Hi,

Just a reminder that today is the deadline for submitting PI requests for
Fx 62.

Regards,
Tom


On Tue, Apr 24, 2018 at 9:16 PM, Tom Grabowski 
wrote:

> Hi,
>
> Similar to what QA did for previous Firefox feature testing prioritization
> ,
> we would like to do the same for Fx62. In order to help with the process, 
> *please
> submit your pi-request
>  by May 2nd. *This
> is needed to assure QA will be involved in your feature development work
> for the next Nightly 62 cycle.
>
>
> *Q: What happens after the deadline?*
> A: After the deadline QA will come back with a prioritized list of work
> that represents what we are committing to for the next cycle. We want to
> ensure this list matches eng and product expectations.
>
> *Q: What if I miss the deadline?*
> A: We reserve the right to say that we can't pick up work for late
> requests in the current cycle. You can still develop and execute your own
> test plan or defer the work to the following cycle.
>
> *Q: What about unknown or unexpected requests? What if there is a business
> reason for a late request? What do we do with experiments and System
> Add-ons?*
> A: In order to remain flexible, we will keep some percentage of time open
> for requests like these.
>
> *Q: There's no way I'm going to remember to do this. *
> A: Do it now! I'll also send out a reminder next week.
>
> Thanks,
> Tom
>
>
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: AudioWorklet

[Robert O'Callahan]

On Wed, May 2, 2018 at 9:21 PM, Karl Tomlinson  wrote:

> It seems that Chrome works around this by choosing to garbage
> collect input nodes even when their presence is specified to
> require (observable) AudioWorkletProcessor.process() calls.
> This garbage collection is performed in a way that causes the
> process() calls to be halted (which stops sound production), and
> so the AudioWorkletProcessor can subsequently also be garbage
> collected if there are no rooted references, as usual.
>
> Having the behavior of AudioWorkletProcess depend on whether or
> not the client maintains references to input nodes is not
> something I'd like to implement.  It would be comparable to an
> audio element stopping playback at a time when an implementation
> chooses to perform garbage collection after the client has removed
> its last reference.  It is contrary to [[TAG design principles]].
> The Chrome approach seems to be based on a different understanding
> of [[AudioNode Lifetime]].
>

Making GC timing observable is a big, big problem. I hope you escalate this
aggressively with the Chrome team.

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: AudioWorklet

[Karl Tomlinson]

=Summary/benefits:

"The AudioWorklet object allows developers to supply scripts
 (such as JavaScript or WebAssembly code) to process audio on the
 rendering thread, supporting custom AudioNodes." [[Concepts]]

Allowing scripts to process audio on the rendering thread is
important for low latency general client-side generation or
processing of audio, free from problems of main thread delays.
This is what game developers, for example, have wanted for some
time.  Other parts of the Web Audio API may have been presented in
the past as solutions, but they were not a good fit in general.

A MessageChannel permits, for example, decoding on a web worker
thread and delivery on an audio thread, with no main thread
influence.

Custom AudioNodes would be important as a way for developers to
extend the Web Audio API.  Hopefully we may no longer even need to
add more special-purpose nodes to the API surface.  See, however,
Usability/interoperability concerns below.

Some work has already landed in Gecko, but I'm not aware of a
previous explicit intent to implement.

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

=Link to standard:
https://webaudio.github.io/web-audio-api/#audioworklet

=Platform coverage:
Desktop + Android.

=Estimated or target release:
When ready,
which may require resolution of GC/interoperability concerns below.

=Preference behind which this will be implemented: 
dom.audioWorklet.enabled and dom.worklet.enabled

=Is this feature enabled by default in sandboxed iframes?
No.
=If not, is there a proposed sandbox flag to enable it?
Yes, "allow-scripts".

=DevTools bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1458445

=Do other browser engines implement this? 
Blink: since Chrome 66, Opera 53.
https://www.chromestatus.com/feature/4588498229133312
Edge: bug assigned.
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/15812544/
Webkit: no indication.
https://bugs.webkit.org/show_bug.cgi?id=182506

=web-platform-tests:
https://github.com/w3c/web-platform-tests/tree/master/webaudio/the-audio-api/the-audioworklet-interface

=Secure contexts:
Yes.

=Usability/interoperability concerns:

AudioNodes are often typically set up, scheduled, and forgotten.
Once they have finished what they have been scheduled to do and
upstream nodes have also finished, associated resources can be
reclaimed, but some effects on downstream nodes remain.

AudioWorkletNode, as currently specified, OTOH, is different.
There is provision through an [[active source]] flag for an
AudioWorkletProcessor to indicate that if there are no further
inputs, then it no longer needs to perform further processing.
However, the client needs to disconnect the inputs when finished.
If the input nodes are forgotten (as is typical), then processing
continues repeatedly and indefinitely (unless the whole
AudioContext is stopped).  The need for clients to keep track of
whether inputs to these nodes have finished makes
AudioWorkletNodes with inputs second class nodes in practice.

A solution based on silent input rather than connection count was
proposed in https://github.com/WebAudio/web-audio-api/issues/1453
but this appears to have been rejected.

It seems that Chrome works around this by choosing to garbage
collect input nodes even when their presence is specified to
require (observable) AudioWorkletProcessor.process() calls.
This garbage collection is performed in a way that causes the
process() calls to be halted (which stops sound production), and
so the AudioWorkletProcessor can subsequently also be garbage
collected if there are no rooted references, as usual.

Having the behavior of AudioWorkletProcess depend on whether or
not the client maintains references to input nodes is not
something I'd like to implement.  It would be comparable to an
audio element stopping playback at a time when an implementation
chooses to perform garbage collection after the client has removed
its last reference.  It is contrary to [[TAG design principles]].
The Chrome approach seems to be based on a different understanding
of [[AudioNode Lifetime]].

Because Chrome reclaims CPU and memory resources even when the
client does not disconnect inputs from AudioWorkletNode, authors
are likely to forget to track input nodes, in which case their
applications will have performance problems in implementations
with deterministic behavior.

=Security/privacy concerns:

The audio thread runs with reasonably precise timing, providing a
clock edge.

The additional surface from AudioWorklet is that script can run on
the audio thread, at the precise time, and send messages to other
threads, rather than merely having browser-messages from the audio
thread to the main thread.

This may be mitigated to some extent by slightly reduced precision
from [[AudioIPC]] and perhaps by using tail dispatch for messages
from the audio thread.

[[Concepts]] https://webaudio.github.io/web-audio-api/#AudioWorklet-concepts
[[active source]]