Intent to remove: isRemote member in WebRTC getStats() results

[Jan-Ivar Bruaroey]

We're removing the isRemote member of the RTCRTPStreamStats [1] 
dictionary used to identify remote statistics returned from the 
peerConnection.getStats() method in WebRTC. [2]


The spec changed in 2017 to explicit types instead of this boolean. [3]

We just landed a deprecation warning in Nightly 63. [4]

We plan on removing isRemote in 65, as the warning says. [5]

We plan to warn in 63-64, but for technical reasons can't warn in 65.

The transition plan involves educating web developers to use the 
existing remoteId API, which remains unaffected by this transition.

Full details are in https://blog.mozilla.org/webrtc/getstats-isremote-65

Compatibility:
 - Chrome does not yet return remote statistics from the spec's latest
   pc.getStats() API, only local stats.
 - Safari implements this subset of getStats() similar to Firefox today.
 - Edge doesn't implement RTCPeerConnection, though there's a shim.

.: Jan-Ivar :.

[1] 
https://w3c.github.io/webrtc-stats/archives/20170330/webrtc-stats.html#dom-rtcrtpstreamstats-isremote

[2] http://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-getstats
[3] https://github.com/w3c/webrtc-stats/pull/191/files
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1393306
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1380555

PS: There’s also an isRemote member in RTCIceCandidateStats which 
remains unaffected.

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

[L10n][BiDi] Fluent now controls content directionality

[Zibi Braniecki (Gandalf)]

Hi all,

A small update from the Fluent world - with landing of bug 1480798 Fluent
now controls the directionality of its roots.

That means that you don't need to do any special magic for RTL locales, as
we will set `localedir` and `dir` (XUL and HTML) attributes on the document
element and flip it correctly in case of a locale change.

For most of the layout it is advised to write as much of it as possible in
a directionality-independent way (so first/last rather than left/right),
but if special rules for direction are necessary, `html[dir=rtl]` and
`html[dir=ltr]` should be enough!

Once exception is pseudolocales, where strategy `bidi` does not currently
automatically trigger directionality switch. I filled bug 1481325 to fix
that.

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

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

[Boris Zbarsky]

On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote:
whereas our plan for that was to ask users once, with a 
"remember=yes" prompt.


For what it's worth, I've been getting this prompt a _lot_ recently; 
presumably I finally updated to a nightly that does the prompt.


As a user, I have been tending to uncheck the "remember" checkbox, 
because I don't understand the implications of having the answer 
remembered and how it would affect the site's behavior in the future...


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

Re: Intent to ship MediaSource SourceBuffer.changeType

[Boris Zbarsky]

On 8/6/18 5:37 AM, Jean-Yves Avenard wrote:

enable by default changeType method on MediaSource’s Source Buffer


To be clear, this is enabling by default on all channels, right?


The method has been availably since 61 behind the preference 
media.mediasource.experimental.enabled


But not default-enabled anywhere, so not much tested?

How stable is the spec?

What is the status of implementation or interest in other browsers?

What is the status of interest from authors?

Put another way, if we thought this was a safe change why did we have it 
off by default to start with?  Were there substantive changes to the 
code since 61 that prevented us from enabling by default before now?


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

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

[Jan-Ivar Bruaroey]

On 8/1/18 3:36 AM, Chris Pearce wrote:

On Tuesday, July 31, 2018 at 9:05:03 AM UTC+12, Jan-Ivar Bruaroey wrote:

On 7/29/18 10:39 PM, Chris Pearce wrote:

Summary: HTMLMediaElement.allowedToPlay allows web authors to determine in 
advance of calling HTMLMediaElement.play() whether the HTMLMediaElement in its 
current state would be allowed to play, or would be blocked by the browser's 
autoplay blocking policies.

This is useful to web authors as if they can't autoplay they may prefer to 
download a poster image instead of paying the price of downloading media data.

This feature is particularly useful for Firefox, as web authors can poll 
HTMLMediaElement.allowedToPlay to determine whether a permission prompt would 
show if they were to call play().


Doesn't this amputate the user flow we just implemented?

Without this attribute, Netflix queues up rich media, Firefox asks the
user if they want autoplay, who answers "Duh, it's Netflix", and levels
up to auto-playing Netflix forever.

With this attribute, Netflix sees HTMLMediaElement.allowedToPlay ==
false, and downloads a poster image instead. User must click to get
engaging media, which now takes longer to load, and they never level up
to auto-playing Netflix?

Doesn't seem like an improvement. Am I missing something?


Without this attribute, sites that are determined to avoid showing the doorhanger have no 
option other than to never autoplay ever in Firefox. With this attribute, they can detect 
when they can "safely" start to autoplay video if the user otherwise unblocks 
autoplay.


My first reaction to this was:

How can the user unblock autoplay on sites determined to never show the 
doorhanger?


But then I realized we're mixing terms.

With "user otherwise unblocks autoplay" you mean "user gesture".
What I call "unblocking autoplay" you call "whitelisting".

It sounds like allowedToPlay would be used to entirely sidestep the 
autoplay permission model we just implemented, rendering Firefox 
identical to Chrome in behavior.


Except not identical, but much poorer, since Chrome would whitelist 
Netflix, whereas our plan for that was to ask users once, with a 
"remember=yes" prompt. If sites sidestep this prompt, then what's our 
whitelist story?


Don't we need a functional plan to let users whitelist Netflix? Doesn't 
this attribute work against that?



To continue your example of Netflix, if the user clicked somewhere, say to 
select their Netflix profile, or click to login or a browse a category or 
side-scroll their catalog, then they'd gesture activate the document and the 
site would be able to autoplay, without a doorhanger.

I think you're basically correct that sites that actively use allowedToPlay to 
avoid the doorhanger would also avoid being whitelisted.


Netflix doesn't need a new API to circumvent our doorhanger and blast 
audio on the first user gesture. That seems easily shimmable:


 1. Test Firefox version
 2. If new, avoid autoplay on pageload
 2. various.forEach((t, n) => t.addEventListener(n, () => audio.play());

What's the benefit to users from standardizing an API to circumvent our UX?


I think the only thing that you're missing is how vehemently some sites are in 
their desire to avoid the doorhanger prompt.


No, I'm also missing why we should listen to them.

If Netflix fights our doorhanger, then they're fighting our best attempt 
to whitelist them.


Regardless, something being contentious is usually a bad sign for 
standardization.



cpearce.


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

Re: Intent to ship MediaSource SourceBuffer.changeType

[Jean-Yves Avenard]

Hi

> On 6 Aug 2018, at 9:12 pm, Nils Ohlmeier  wrote:
> 
> Which version of Firefox are you planing to ship this?
> 
> Thanks
>  Nils


Sorry, my bad.

63.. The feature was introduced in 61.

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stopgap for Commit Series in Phabricator

[Ted Mielczarek]

Thanks for this, Kris! Just an FYI for anyone planning to try this: I was 
behind a few versions on Mercurial (at 4.3) and I had to update to 4.7 for this 
extension to work.

-Ted

On Thu, Jul 26, 2018, at 12:09 PM, Kris Maglione wrote:
> Here's an approximate equivalent for hg which doesn't require 
> Arcanist:
> 
> https://bitbucket.org/kmaglione/hgext/src/default/phabricator.py
> 
> It's a slightly modified version of stock hg Phabricator plugin 
> (which we apparently have gps to thank for inspiring) which 
> handles parsing bug IDs and reviewers from commit messages.
> 
> You just need to add something like this to your .hgrc:
> 
> [phabricator]
> url = https://phabricator.services.mozilla.com/
> callsign = MOZILLACENTRAL
> 
> [auth]
> mozilla.schemes = https
> mozilla.prefix = phabricator.services.mozilla.com
> mozilla.phabtoken = cli-...
> 
> and then use `hg phabsend` to push a commit series (or `hg phabread` 
> to import one).
> 
> On Wed, Jul 25, 2018 at 04:31:51PM -0400, Nika Layzell wrote:
> >While our services team is working on making a reliable & maintained tool
> >for handling commit series with Phabricator, I threw together something
> >small to use as a stop-gap for pushing large commit series to Phabricator
> >and updating them.
> >
> >It currently works as a wrapper around Arcanist, and *only supports git*
> >(as I don't know how hg works enough to get it to work reliably), but
> >should allow pushing a range of commits as revisions without touching the
> >working tree, automatic dependency relationships, bug number filling, and
> >reviewer field population.
> >
> >I called it 'phlay' (splinter => flay; flay + phabricator => phlay).
> >
> >GitHub: https://github.com/mystor/phlay
> >Tweet w/ short demo clip:
> >https://twitter.com/kneecaw/status/1021434807325163523
> >
> >I've used it to push pretty-much all of my recent patch series to
> >Phabricator, and it's saved me a good amount of time, so I figured I'd let
> >people know. Feel free to poke me on IRC if you have questions.
> >
> >- nika
> 
> -- 
> Kris Maglione
> 
> [T]he people can always be brought to the bidding of the leaders.
> That is easy.  All you have to do is tell them they are being attacked
> and denounce the pacifists for lack of patriotism and exposing the
> country to danger.  It works the same way in any country.
>   --Herman Göring
> 
> ___
> 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 ship MediaSource SourceBuffer.changeType

[Nils Ohlmeier]

Which version of Firefox are you planing to ship this?

Thanks
  Nils

> On Aug 6, 2018, at 02:37, Jean-Yves Avenard  wrote:
> 
> Summary:
> 
> enable by default changeType method on MediaSource’s Source Buffer, allowing 
> to change content type (codecs and/or container) on the fly…
> The method has been availably since 61 behind the preference 
> media.mediasource.experimental.enabled
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1481166 
> 
> 
> Detail:
> 
> Up to now, when using Media Source Extension, you had to create a source 
> buffer of a specific type using the MediaSource.addSourceBuffer method, 
> providing the mime type describing the container and optionally the codec. 
> You could then no longer change the container nor the codec.
> 
> Comes changeType , it allows to mix different codec within the same video 
> element.
> One particular use case would be to use different codecs according to the 
> selected resolution.
> 
> Like using AV1 for the very low bitrate due to the exceptional performance of 
> AV1 there, and switch later to VP9 or H264 as they are a bit more friendly 
> resource-wise.
> 
> JY___
> 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: PSA: Avoid Visual Studio 2017 15.7.0

[Jeff Gilbert]

Consider instead building with clang-cl:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Building_Firefox_on_Windows_with_clang-cl

If you build with clang-cl, you can keep the newest
(gecko-incompatible) version of MSVC installed, which is particularly
useful if you build other modern codebases.

On Fri, May 11, 2018 at 3:01 PM, Matthew N.  wrote:
> On 2018-05-08 6:40 a.m., Ryan VanderMeulen wrote:
>>
>> Yesterday, Microsoft released Visual Studio 2017 15.7.0. Unfortunately, it
>> is currently not usable for building Firefox due to bug 1458247 (internal
>> compiler errors in WebRTC code). The bug was already reported and
>> confirmed
>> upstream during the 15.7 preview cycle, but unfortunately the final
>> release
>> still shipped with the bug present.
>>
>> At this point, there are no workarounds available for this issue, so avoid
>> the update if you want to be able to continue building Firefox.
>
>
> If you need to update to 15.6 but hadn't yet, you can download old versions
> at
> https://docs.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017
>
> - MattN
>
> ___
> 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 MediaSource SourceBuffer.changeType

[Jean-Yves Avenard]

Summary:

enable by default changeType method on MediaSource’s Source Buffer, allowing to 
change content type (codecs and/or container) on the fly…
The method has been availably since 61 behind the preference 
media.mediasource.experimental.enabled

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


Detail:

Up to now, when using Media Source Extension, you had to create a source buffer 
of a specific type using the MediaSource.addSourceBuffer method, providing the 
mime type describing the container and optionally the codec. You could then no 
longer change the container nor the codec.

Comes changeType , it allows to mix different codec within the same video 
element.
One particular use case would be to use different codecs according to the 
selected resolution.

Like using AV1 for the very low bitrate due to the exceptional performance of 
AV1 there, and switch later to VP9 or H264 as they are a bit more friendly 
resource-wise.

JY

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ./mach try fuzzy: A Try Syntax Alternative

[James Graham]

On 06/08/2018 01:25, Botond Ballo wrote:

Is there an easy way to do a T-push (builds on all platforms, tests on
one platform only) with |mach try fuzzy|?

I usually do T-pushes using try syntax, by Trychooser seems to be out
of date when it comes to building a T-push syntax for Android, so I'm
at a loss as to how to do a T-push for Android right now.


There are a couple of options. Interactively you can select all the 
builds you want, press ctrl+a (or whatever the select-all keybinding you 
have configured is), then do the same again with the tests you want, 
then accept all your choices.


If you want to construct a single query string that can be reused with 
--save, something like 'test-linux64 | build !ccov !pgo !msvc' seems to 
select all builds and tests just on linux64. Unfortunately I can't 
figure out any way to logically group expressions, which does make 
composing multiple terms more tricky.

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