Re: Intent to ship: Unprefixed Fullscreen API

[Chris Pearce]

On Tuesday, September 18, 2018 at 11:48:19 AM UTC+12, Xidorn Quan wrote:
> As of Firefox 64, I intend to turn on unprefixed Fullscreen API by default on 
> all platforms. It has been developed behind the 
> full-screen-api.unprefix.enabled preference.
> 
> Bug to turn on by default: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1269276
> 
> Unprefixed Fullscreen API has been enabled in Nightly since Firefox 47. We 
> once attempted to ship it at that time, but failed because of some webcompat 
> concerns which happen only when unprefixed Fullscreen API is present. Since 
> then, the spec has been revised to address some of the issues, but some of 
> them were not fixable from our side, so I hoped to have other browsers do 
> coordinated shipping with us.
> 
> After years, Chrome / Blink eventually caught up the spec, and it reached a 
> point that they are attempting to ship it now. I think this is the best 
> chance ever we can have unprefixed Fullscreen API actually available on the 
> web. Chrome will ship it in Chrome 71 which reaches stable on Dec 4, and 
> Firefox 64 will reach release on Dec 11, so it's roughly the same time frame.
> 
> Notably, there are two feature changes since our last attempt to unprefix 
> Fullscreen API:
> 1. Fullscreen related events are now dispatched to element when it is still 
> connected in the same document, which matches other browsers' behavior and 
> provides better modularization opportunity.
> 2. Element.requestFullscreen() and Document.exitFullscreen() now return 
> Promise which gets resolved when fullscreen change finishes.
> 
> I'd also like to deprecate the prefixed Fullscreen API, but probably we 
> should do that only after unprefixed Fullscreen API reaches release.
> 
> - Xidorn

Great work, happy to see fullscreen finally move to unprefixed!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

[Chris Pearce]

On Wednesday, August 8, 2018 at 4:58:28 PM UTC-7, Jan-Ivar Bruaroey wrote:
> On 8/8/18 12:43 PM, Chris Pearce wrote:
> > Hi Jib,
> > 
> > I appreciate that you care passionately about our users' best interests.
> > 
> > Seeing as you asked "why don't you just?"... Here's why we "didn't just"...
> > 
> > On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
> >> On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote:
> >>> On 8/1/18 3:36 AM, Chris Pearce wrote:
> >>>> 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.
> >>
> >> To clarify, I care about Netflix, which is why I question giving up on
> >> persisting autoplay for them, which is what allowedToPlay does.
> >>
> >> AFAICT allowedToPlay's sole purpose is to avoid our doorhanger.
> > 
> > Sites are already trying to feature detect whether they can autoplay 
> > audible video and present different behaviour when they can't. There are 
> > established solutions for this that pre-date us talking about doing a 
> > doorhanger. So I don't think we can conclude that authors are doing this to 
> > avoid our doorhanger.
> > 
> > Many of the major US news sites as well as the BBC now try to autoplay 
> > audibly, and if that is blocked, they fallback to playing inaudiblby and 
> > showing an unmute button.
> 
> Right, because of Chrome. This is my point. allowedToPlay plays into 
> Chrome's autoplay policy (pardon the pun), not ours.
> 
> Chrome's "path to whitelisting" policy appears to be: Don't bother 
> trying unless you're whitelisted or until user engagement kicks in.
> 
> Our "path to whitelisting" policy appears to be: Try, and we'll ask the 
> user to whitelist you. If you don't try, we can't help you.
> 
>  From a web developer's perspective, this seems incompatible.
> 
> So allowedToPlay makes sense in Chrome, not in Firefox at the moment.
> 
> Seems to me we need a better "path to whitelisting" strategy, before we 
> help bury the one we have.
> 
> Once we have a working "path to whitelisting" policy, that's not 
> thwarted by allowedToPlay or modernizr, I see no problem with 
> allowedToPlay, but it appears we don't.
> 
> What concerns me, is we seem intent to land without this in place...
> 
>Firefox 62: Netflix autoplays
>Firefox 63: Netflix no longer autoplays
>Chrome: Netflix autoplays
> 
> :-(
> 
> > I was also pointed at https://www.npmjs.com/package/modernizr which which 
> > is a web framework which is feature sniffing whether audible autoplay works 
> > by trying to play a media with a silent audio track. It does this on load, 
> > even if the page author hasn't signaled any intention to use video. NPMJS 
> > lists that as getting 41k weekly downloads, and this framework would cause 
> > sites that are not obviously using media to have a prompt appear in Firefox 
> > for maybe no benefit. I want to avoid that.
> > 
> > Many of these packages which detect whether audible autoplay works have 
> > timeouts so that if the play() promise is not resolved within some short 
> > time they assume that they can't autoplay, which doesn't play nice with us 
> > delaying resolving the play() promise while we wait for the user to click 
> > the prompt.
> > 
> > Sites were trying to detect whether they can audibly autoplay before 
> > Firefox had a prompt, so making it easier/cheaper/faster for them whilst 
> > also having a side benefit of avoiding the prompt seems reasonable.
> > 
> > 
> > 
> > 
> >> I've heard two reasons to fear our doorhanger:
> >>
> >> 1. Sites doesn't want to get blocked.
> >>
> >> This seems bogus, because "getting blocked" appears no different from
> >> avoiding the prompt with allowedToPlay. Both prevent the prompt.
> >>
> >> Try it yourself: https://jsfiddle.net/jib1/rwkLaofx/show
> >> Press "Don't Allow", then click anywhere on the page to play.
> >>
> >> In other words, users aren't blocking audio, only un-gestured audio,
> >> which shouldn't matter to sites who already avoid it with allowedToPlay.
> > 
> > 
> > It's not clear to me that "Sites doesn't want to ge

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

[Chris Pearce]

On Wednesday, August 8, 2018 at 9:54:06 AM UTC-7, Boris Zbarsky wrote:
> On 8/8/18 12:43 PM, Chris Pearce wrote:
> > On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
> >> To clarify, I care about Netflix, which is why I question giving up on
> >> persisting autoplay for them, which is what allowedToPlay does.
> 
> So I have a question.  Would it be at all useful to have an explicit way 
> for a site to ask for a persistent permission grant (as opposed to the 
> implicit "just try to play something")?  Would netflix use that?  Or 
> would they avoid it for the same reasons as their current avoidance of 
> the prompt?  Assuming sites would use it, would we be able to sell other 
> browsers on such an API?
> 
> There's a hard problem here at heart where the APIs are being designed 
> around the UX, and the different browsers have very different UX goals, 
> afaict.
> 
> -Boris

I think that's a good idea.

I had proposed that autoplay-media permissions be exposed as part of the 
Permisisons API here https://github.com/w3c/permissions/issues/172 which I 
think would mean that they could be explicitly requested? Google weren't keen 
on that idea as it doesn't map well to their implicit MEI method.

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

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

[Chris Pearce]

Hi Jib,

I appreciate that you care passionately about our users' best interests.

Seeing as you asked "why don't you just?"... Here's why we "didn't just"...

On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
> On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote:
> > On 8/1/18 3:36 AM, Chris Pearce wrote:
> >> 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.
> 
> To clarify, I care about Netflix, which is why I question giving up on 
> persisting autoplay for them, which is what allowedToPlay does.
> 
> AFAICT allowedToPlay's sole purpose is to avoid our doorhanger.

Sites are already trying to feature detect whether they can autoplay audible 
video and present different behaviour when they can't. There are established 
solutions for this that pre-date us talking about doing a doorhanger. So I 
don't think we can conclude that authors are doing this to avoid our doorhanger.

Many of the major US news sites as well as the BBC now try to autoplay audibly, 
and if that is blocked, they fallback to playing inaudiblby and showing an 
unmute button.

I was also pointed at https://www.npmjs.com/package/modernizr which which is a 
web framework which is feature sniffing whether audible autoplay works by 
trying to play a media with a silent audio track. It does this on load, even if 
the page author hasn't signaled any intention to use video. NPMJS lists that as 
getting 41k weekly downloads, and this framework would cause sites that are not 
obviously using media to have a prompt appear in Firefox for maybe no benefit. 
I want to avoid that.

Many of these packages which detect whether audible autoplay works have 
timeouts so that if the play() promise is not resolved within some short time 
they assume that they can't autoplay, which doesn't play nice with us delaying 
resolving the play() promise while we wait for the user to click the prompt.

Sites were trying to detect whether they can audibly autoplay before Firefox 
had a prompt, so making it easier/cheaper/faster for them whilst also having a 
side benefit of avoiding the prompt seems reasonable.




> I've heard two reasons to fear our doorhanger:
> 
>1. Sites doesn't want to get blocked.
>
> This seems bogus, because "getting blocked" appears no different from 
> avoiding the prompt with allowedToPlay. Both prevent the prompt.
> 
> Try it yourself: https://jsfiddle.net/jib1/rwkLaofx/show
> Press "Don't Allow", then click anywhere on the page to play.
> 
> In other words, users aren't blocking audio, only un-gestured audio, 
> which shouldn't matter to sites who already avoid it with allowedToPlay.


It's not clear to me that "Sites doesn't want to get blocked" is in our users' 
interest, so I'm not going to contest this.

 
> Also, allowedToPlay will never suddenly return true if used to suppress 
> the prompt, because we have no other whitelisting strategy.


allowedToPlay will start returning true when the page is gesture activated.

For example, when I open into Netflix, I am greeted with a profile selection 
screen from which I can choose between my profile, my wife's profile, or my 
kids' profile. The click to select a profile gesture activates the tab for me, 
so I normally don't see the prompt on Netflix FWIW.


> 
>2. User testing shows many users don't understand the prompt.
> 
> This one makes sense to me. If avoiding our one-time prompt matters more 
> to them than autoplay itself, it's a sign our prompt isn't great. We 
> should fix that, not help sites opt out.


The prompt exists because there are some cases where users have a reasonable 
expectation that autoplay audible audio should work without interacting with 
the page first. For example deep links into YouTube/Netflix videos, 
notification sounds for messaging sites, and the long tail of things that 
Chrome broke in https://bugs.chromium.org/p/chromium/issues/detail?id=840866 
(some of which are WebAudio, which we're not blocking yet).

I wanted to solve this by shipping our own custom whitelist (like Chrome and 
Safari), but we couldn't figure out how to objectively generate one without 
phoning home with our users' browsing history, and that's against our data 
collection policies.


> 
> 
> Here's my take on our prompt:
> 
> I love that we went with a visible user agent feature instead of 
> breaking the web. Even the permission part, partly. The management part.
> 
> But the prompt itself is too complicated. It's hard to glean how little 
> is at stake: delaying audio by a mere click in many cases.
>

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

[Chris Pearce]

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.

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.

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

cpearce.

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

Intent to implement and ship: HTMLMediaElement.allowedToPlay

[Chris Pearce]

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

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

Spec: being developed here https://github.com/whatwg/html/issues/3617

Platform coverage: All

Target release: The same release as block autoplay, so 63, or soon after.

Preference: None

Support in other engines: There is consensus in the WhatWG github issue, but no 
explicit commitments from other implementors yet. We decided we should push 
ahead with this for Firefox because of our strategy of prompting the user for 
permission makes this feature particularly useful for us, as this feature 
provides a way for sites to avoid the prompt if desired.

Secure Context: No. HTMLMediaElement is already shipping elsewhere outside a 
secure context.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: block audible autoplay media intervention

[Chris Pearce]

On Wednesday, July 4, 2018 at 11:38:21 AM UTC+12, Chris Pearce wrote:
> Intent to ship: block audible autoplay media intervention
> 
> SUMMARY:
> 
> We intend to change the behaviour of HTMLMediaElement to block autoplay of 
> audible audio and video in Firefox on desktop and mobile.
> 
> We are not going to block WebAudio at the same time. While we do plan to 
> block audible autoplay of WebAudio content in the near future, we have not 
> finalized our WebAudio blocking logic or intended ship date for blocking 
> WebAudio.
> 
> 
> TIMELINE:
> 
> We intend to run shield studies on the user impact of enabling 
> HTMLMediaElement autoplay blocking. If those go well we hope to ship in 
> Firefox 63 (2018-10-23) or Firefox 64 (2018-12-11). Upon conclusion of our 
> experiments, I’ll follow up here with a confirmed ship date for this feature.
> 
> We hope to block autoplay in WebAudio in a release soon after, hopefully 
> Firefox 64 or 65.
> 
> 
> DETAILS:
> 
> We intend to block autoplay of HTMLMediaElement in tabs which haven't had 
> user interaction. Web authors should assume that they require a user gesture 
> (mouse click on a "play" button for example) in order to play audible media.
> 
> HTMLMediaElements with a "muted" attribute or "volume=0" are still allowed to 
> play.
> 
> As with other browsers implementing this feature, we express playback being 
> blocked by rejecting the promise returned by HTMLMediaElement.play(). Web 
> authors should always check whether the promise returned by 
> HTMLMediaElement.play() is rejected, and handle that case accordingly.
> 
> We also plan to allow users to create their own whitelist of sites which they 
> trust to autoplay.
> 
> We are planning to experiment via shield studies with prompting users to 
> approve/block playback on sites that try to autoplay before receiving user 
> interaction.
> 
> 
> ADVICE FOR WEB AUTHORS:
> 
> In general, the advice that applies to other browsers [1][2] with respect to 
> autoplaying media will apply to Firefox as well; you cannot assume that you 
> can just call HTMLMediaElement.play() for audible media and expect it to 
> always play. You should always check whether the play promise is rejected, 
> and handle that case accordingly.
> 
> For example:
> 
> var promise = document.querySelector('video').play();
> 
> if (promise !== undefined) {
> promise.catch(error => {
> // Auto-play was prevented
> // Show a UI element to let the user manually start playback
> }).then(() => {
> // Auto-play started
> });
> }
> 
> (This example comes from WebKit’s announcement on blocking autoplay [2])
> 
> To test block autoplay in Firefox 63 (currently in Firefox Nightly channel), 
> download the latest Nightly and open about:config in the URL bar and set the 
> preferences:
> 
> media.autoplay.enabled=false
> media.autoplay.enabled.user-gestures-needed=true
> media.autoplay.ask-permission=true
> 
> 
> Tracking bug: (block-autoplay) 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1376321
> 
> 
> If you find bugs, please file them via this link and CC or need-info me 
> (cpearce), and mark them blocking bug 1376321:
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Audio%2FVideo%3A%20Playback
> 
> 
> I will follow up with a confirmed ship date for block audible autoplay in 
> Firefox once we have one.
> 
> 
> 
> [1] https://developers.google.com/web/updates/2017/09/autoplay-policy-changes
> [2] https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/


Block autoplay is now enabled by default in Nightly (only).

If you find bugs, please file them in "Core > Audio/Video > Playback" or via 
this link https://mzl.la/2JHYjlF and CC or need-info me (cpearce), and mark 
them blocking bug 1376321.

If you have any feedback on whether you find the feature good, bad, or ugly, 
please email/IRC me, or let the team know in the block_autoplay Mozilla slack 
channel.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: block audible autoplay media intervention

[Chris Pearce]

On Tuesday, July 10, 2018 at 7:30:38 AM UTC+12, Mounir Lamouri wrote:
> On Fri, 6 Jul 2018, at 15:35, Chris Pearce wrote:
> > On Saturday, July 7, 2018 at 5:04:28 AM UTC+12, Mounir Lamouri wrote:
> > > On Fri, 6 Jul 2018, at 00:49, Chris Pearce wrote:
> > > > On Friday, July 6, 2018 at 3:10:58 AM UTC+12, Mounir Lamouri wrote:
> > > > > On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote:
> > > > > > > > HTMLMediaElements with a "muted" attribute or "volume=0" are 
> > > > > > > > still
> > > > > > > > allowed to play.
> > > > > > >
> > > > > > > Chrome and Safari allows autoplay only when the playback is 
> > > > > > > muted. The
> > > > > > > spec allows side effect for setting `muted = false;`. What will 
> > > > > > > happen for
> > > > > > > a website that changes the volume from 0 to something else?
> > > > > > >
> > > > > > >
> > > > > > 
> > > > > > If an HTMLMediaElement starts playing with muted/volume=0 and then 
> > > > > > script
> > > > > > sets it to unmuted/volume>0, then we'll pause the media.
> > > > > 
> > > > > The volume=0 behaviour isn't compatible with Blink and WebKit. Would 
> > > > > it be worth only use muted for consistency between browsers?
> > > > 
> > > > This code gives me the impression that WebKit does in fact block volume 
> > > > > 0 media:
> > > > https://github.com/WebKit/webkit/blob/2d78ab563d64545ead630115bcd55047d0400fac/Source/WebCore/html/MediaElementSession.cpp#L303
> > > > 
> > > > So maybe Blink should consider changing to be consistent with other 
> > > > browsers? ;)
> > > 
> > > That's interesting. We spec'd something in HTML and Safari did not 
> > > mention this. It's not in their documentation nor ours. What's the 
> > > benefit of allowing volume=0 to autoplay?
> > 
> > 
> > Setting volume to 0 is another easy way to make videos inaudible, and we 
> > want inaudible video to be able to autoplay. So I'd flip that question 
> > around and ask why you think volume=0 video should not autoplay but a 
> > video without an audio track should? Both are inaudible.
> 
> `muted` and the presence of an audio track clear distinguishable signals as 
> they are boolean and declarative. A video that has volume 0 could be for 
> various reasons. Furthermore, requiring `muted` or `volume` seems slightly 
> odd as they both apply to the HTML content while the audio track metadata is 
> at a different level so can offer benefits if for example, modifying the 
> content is possible but not the page.
> 
> FWIW, we could add this in Blink if it can help with x-browser compat but 
> I've never heard of a website asking for this nor did I see articles 
> suggesting using volume=0 even from Apple. Given that it would require the 
> website to set `video.volume = 0;` in script, it is less powerful than 
> `muted` that can be used as a content attribute too.
> 
> > > > > > > Also, will autoplay be allowed when the video has no audio track?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > Our autoplay logic ignores whether the media resource has an audio 
> > > > > > track;
> > > > > > it makes our implementation simpler, and if an author knows a media 
> > > > > > should
> > > > > > be inaudible, they can set the muted attribute. So a video element 
> > > > > > playing
> > > > > > a media resource with no audio track and without the muted 
> > > > > > attribute would
> > > > > > still be blocked.
> > > > > 
> > > > > FWIW, WebKit uses the audio track availability and Blink intends to 
> > > > > do this at some point.
> > > > 
> > > > 
> > > > I actually implemented this, landed it, and then ended up reverting it.
> > > > 
> > > > The main problem here is if HTMLMediaElement.play() is called before 
> > > > the 
> > > > load algorithm has reached readyState>=HAVE_METADATA, you won't know 
> > > > whether the media you're loading has audio tracks.
> > > > 
> > > > If you hit this case, you have two options; decide whether to block 
> > >

Re: Intent to ship: block audible autoplay media intervention

[Chris Pearce]

On Saturday, July 7, 2018 at 5:04:28 AM UTC+12, Mounir Lamouri wrote:
> On Fri, 6 Jul 2018, at 00:49, Chris Pearce wrote:
> > On Friday, July 6, 2018 at 3:10:58 AM UTC+12, Mounir Lamouri wrote:
> > > On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote:
> > > > Hi Mounir,
> > > > 
> > > > Replies inline below...
> > > > 
> > > > 
> > > > On Thu, Jul 5, 2018 at 2:56 AM, Mounir Lamouri  
> > > > wrote:
> > > > 
> > > > > Hi Chris,
> > > > >
> > > > > Very excited to see Firefox going forward with autoplay blocking. A 
> > > > > couple
> > > > > of comments inline.
> > > > >
> > > > > On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote:
> > > > > > DETAILS:
> > > > > >
> > > > > > We intend to block autoplay of HTMLMediaElement in tabs which 
> > > > > > haven't
> > > > > > had user interaction. Web authors should assume that they require a 
> > > > > > user
> > > > > > gesture (mouse click on a "play" button for example) in order to 
> > > > > > play
> > > > > > audible media.
> > > > >
> > > > > I assume you will not allow autoplay when navigating into the same
> > > > > website? What about iframes? Will they be allowed to autoplay if the 
> > > > > main
> > > > > frame is allowed to? Will the feature policy be used instead?
> > > > >
> > > > >
> > > > A gesture in any document in the document hierarchy gesture activates 
> > > > the
> > > > top level document, and a document uses the top level document's gesture
> > > > activation status to determine whether it can play (our implementation
> > > > actually differs a bit, but this is the effective behaviour). Gesture
> > > > activation status isn't preserved across navigation. So if the top level
> > > > document navigates, the incoming document hierarchy won't be able to
> > > > autoplay. If a non-top-level document navigates, the new document in the
> > > > iframe will still use the top-level document's gesture activation 
> > > > status,
> > > > and so the iframe's new content document will be able to autoplay.
> > > 
> > > With autoplay coming from third party content, do you consider using 
> > > Feature Policy to block cross origin iframes by default?
> > 
> > 
> > I won't rule out doing something in the spirit providing a way for sites 
> > to control whether subframes are allowed to autoplay in future, but we 
> > won't be doing it as part of our MVP.
> 
> To clarify, your MVP will allow subframes to autoplay if the main frame can, 
> right?
> 


That's correct. If any document in the hierarchy is gesture activated, the 
entire hierarchy is activated.


> > > > > > HTMLMediaElements with a "muted" attribute or "volume=0" are still
> > > > > > allowed to play.
> > > > >
> > > > > Chrome and Safari allows autoplay only when the playback is muted. The
> > > > > spec allows side effect for setting `muted = false;`. What will 
> > > > > happen for
> > > > > a website that changes the volume from 0 to something else?
> > > > >
> > > > >
> > > > 
> > > > If an HTMLMediaElement starts playing with muted/volume=0 and then 
> > > > script
> > > > sets it to unmuted/volume>0, then we'll pause the media.
> > > 
> > > The volume=0 behaviour isn't compatible with Blink and WebKit. Would it 
> > > be worth only use muted for consistency between browsers?
> > 
> > This code gives me the impression that WebKit does in fact block volume 
> > > 0 media:
> > https://github.com/WebKit/webkit/blob/2d78ab563d64545ead630115bcd55047d0400fac/Source/WebCore/html/MediaElementSession.cpp#L303
> > 
> > So maybe Blink should consider changing to be consistent with other 
> > browsers? ;)
> 
> That's interesting. We spec'd something in HTML and Safari did not mention 
> this. It's not in their documentation nor ours. What's the benefit of 
> allowing volume=0 to autoplay?


Setting volume to 0 is another easy way to make videos inaudible, and we want 
inaudible video to be able to autoplay. So I'd flip that question around and 
ask why you think volume=0 video should not autoplay but a video without an 
au

Re: Intent to ship: block audible autoplay media intervention

[Chris Pearce]

On Friday, July 6, 2018 at 3:10:58 AM UTC+12, Mounir Lamouri wrote:
> On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote:
> > Hi Mounir,
> > 
> > Replies inline below...
> > 
> > 
> > On Thu, Jul 5, 2018 at 2:56 AM, Mounir Lamouri  wrote:
> > 
> > > Hi Chris,
> > >
> > > Very excited to see Firefox going forward with autoplay blocking. A couple
> > > of comments inline.
> > >
> > > On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote:
> > > > DETAILS:
> > > >
> > > > We intend to block autoplay of HTMLMediaElement in tabs which haven't
> > > > had user interaction. Web authors should assume that they require a user
> > > > gesture (mouse click on a "play" button for example) in order to play
> > > > audible media.
> > >
> > > I assume you will not allow autoplay when navigating into the same
> > > website? What about iframes? Will they be allowed to autoplay if the main
> > > frame is allowed to? Will the feature policy be used instead?
> > >
> > >
> > A gesture in any document in the document hierarchy gesture activates the
> > top level document, and a document uses the top level document's gesture
> > activation status to determine whether it can play (our implementation
> > actually differs a bit, but this is the effective behaviour). Gesture
> > activation status isn't preserved across navigation. So if the top level
> > document navigates, the incoming document hierarchy won't be able to
> > autoplay. If a non-top-level document navigates, the new document in the
> > iframe will still use the top-level document's gesture activation status,
> > and so the iframe's new content document will be able to autoplay.
> 
> With autoplay coming from third party content, do you consider using Feature 
> Policy to block cross origin iframes by default?


I won't rule out doing something in the spirit providing a way for sites to 
control whether subframes are allowed to autoplay in future, but we won't be 
doing it as part of our MVP.


> > > > HTMLMediaElements with a "muted" attribute or "volume=0" are still
> > > > allowed to play.
> > >
> > > Chrome and Safari allows autoplay only when the playback is muted. The
> > > spec allows side effect for setting `muted = false;`. What will happen for
> > > a website that changes the volume from 0 to something else?
> > >
> > >
> > 
> > If an HTMLMediaElement starts playing with muted/volume=0 and then script
> > sets it to unmuted/volume>0, then we'll pause the media.
> 
> The volume=0 behaviour isn't compatible with Blink and WebKit. Would it be 
> worth only use muted for consistency between browsers?

This code gives me the impression that WebKit does in fact block volume > 0 
media:
https://github.com/WebKit/webkit/blob/2d78ab563d64545ead630115bcd55047d0400fac/Source/WebCore/html/MediaElementSession.cpp#L303

So maybe Blink should consider changing to be consistent with other browsers? ;)


> > > Also, will autoplay be allowed when the video has no audio track?
> > >
> > >
> > >
> > Our autoplay logic ignores whether the media resource has an audio track;
> > it makes our implementation simpler, and if an author knows a media should
> > be inaudible, they can set the muted attribute. So a video element playing
> > a media resource with no audio track and without the muted attribute would
> > still be blocked.
> 
> FWIW, WebKit uses the audio track availability and Blink intends to do this 
> at some point.


I actually implemented this, landed it, and then ended up reverting it.

The main problem here is if HTMLMediaElement.play() is called before the load 
algorithm has reached readyState>=HAVE_METADATA, you won't know whether the 
media you're loading has audio tracks.

If you hit this case, you have two options; decide whether to block immediately 
based on incomplete information, or return the promise and wait until you reach 
loadedmetadata before deciding whether to play.

If you decide based on incomplete information you become racy; the decision you 
make on incomplete information may contradict the decision you'd make based on 
more complete information when the load is further along, and network loads are 
inherently racy. That seems bad.

If you return the promise and yield control to JS you run into compat issues. 
As Jean-Yves mentioned, some sites expect that HTMLMediaElement.play() 
synchronously sets the paused attribute to false and enqueues tasks to fire 
"play", "playing" etc. Safari appears to have a quirks mode where they pretend

Re: Intent to ship: block audible autoplay media intervention

[Chris Pearce]

Hi Mounir,

Replies inline below...


On Thu, Jul 5, 2018 at 2:56 AM, Mounir Lamouri  wrote:

> Hi Chris,
>
> Very excited to see Firefox going forward with autoplay blocking. A couple
> of comments inline.
>
> On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote:
> > DETAILS:
> >
> > We intend to block autoplay of HTMLMediaElement in tabs which haven't
> > had user interaction. Web authors should assume that they require a user
> > gesture (mouse click on a "play" button for example) in order to play
> > audible media.
>
> I assume you will not allow autoplay when navigating into the same
> website? What about iframes? Will they be allowed to autoplay if the main
> frame is allowed to? Will the feature policy be used instead?
>
>
A gesture in any document in the document hierarchy gesture activates the
top level document, and a document uses the top level document's gesture
activation status to determine whether it can play (our implementation
actually differs a bit, but this is the effective behaviour). Gesture
activation status isn't preserved across navigation. So if the top level
document navigates, the incoming document hierarchy won't be able to
autoplay. If a non-top-level document navigates, the new document in the
iframe will still use the top-level document's gesture activation status,
and so the iframe's new content document will be able to autoplay.



> > HTMLMediaElements with a "muted" attribute or "volume=0" are still
> > allowed to play.
>
> Chrome and Safari allows autoplay only when the playback is muted. The
> spec allows side effect for setting `muted = false;`. What will happen for
> a website that changes the volume from 0 to something else?
>
>

If an HTMLMediaElement starts playing with muted/volume=0 and then script
sets it to unmuted/volume>0, then we'll pause the media.



> Also, will autoplay be allowed when the video has no audio track?
>
>
>
Our autoplay logic ignores whether the media resource has an audio track;
it makes our implementation simpler, and if an author knows a media should
be inaudible, they can set the muted attribute. So a video element playing
a media resource with no audio track and without the muted attribute would
still be blocked.


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

Intent to ship: block audible autoplay media intervention

[Chris Pearce]

Intent to ship: block audible autoplay media intervention

SUMMARY:

We intend to change the behaviour of HTMLMediaElement to block autoplay of 
audible audio and video in Firefox on desktop and mobile.

We are not going to block WebAudio at the same time. While we do plan to block 
audible autoplay of WebAudio content in the near future, we have not finalized 
our WebAudio blocking logic or intended ship date for blocking WebAudio.


TIMELINE:

We intend to run shield studies on the user impact of enabling HTMLMediaElement 
autoplay blocking. If those go well we hope to ship in Firefox 63 (2018-10-23) 
or Firefox 64 (2018-12-11). Upon conclusion of our experiments, I’ll follow up 
here with a confirmed ship date for this feature.

We hope to block autoplay in WebAudio in a release soon after, hopefully 
Firefox 64 or 65.


DETAILS:

We intend to block autoplay of HTMLMediaElement in tabs which haven't had user 
interaction. Web authors should assume that they require a user gesture (mouse 
click on a "play" button for example) in order to play audible media.

HTMLMediaElements with a "muted" attribute or "volume=0" are still allowed to 
play.

As with other browsers implementing this feature, we express playback being 
blocked by rejecting the promise returned by HTMLMediaElement.play(). Web 
authors should always check whether the promise returned by 
HTMLMediaElement.play() is rejected, and handle that case accordingly.

We also plan to allow users to create their own whitelist of sites which they 
trust to autoplay.

We are planning to experiment via shield studies with prompting users to 
approve/block playback on sites that try to autoplay before receiving user 
interaction.


ADVICE FOR WEB AUTHORS:

In general, the advice that applies to other browsers [1][2] with respect to 
autoplaying media will apply to Firefox as well; you cannot assume that you can 
just call HTMLMediaElement.play() for audible media and expect it to always 
play. You should always check whether the play promise is rejected, and handle 
that case accordingly.

For example:

var promise = document.querySelector('video').play();

if (promise !== undefined) {
promise.catch(error => {
// Auto-play was prevented
// Show a UI element to let the user manually start playback
}).then(() => {
// Auto-play started
});
}

(This example comes from WebKit’s announcement on blocking autoplay [2])

To test block autoplay in Firefox 63 (currently in Firefox Nightly channel), 
download the latest Nightly and open about:config in the URL bar and set the 
preferences:

media.autoplay.enabled=false
media.autoplay.enabled.user-gestures-needed=true
media.autoplay.ask-permission=true


Tracking bug: (block-autoplay) 
https://bugzilla.mozilla.org/show_bug.cgi?id=1376321


If you find bugs, please file them via this link and CC or need-info me 
(cpearce), and mark them blocking bug 1376321:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Audio%2FVideo%3A%20Playback


I will follow up with a confirmed ship date for block audible autoplay in 
Firefox once we have one.



[1] https://developers.google.com/web/updates/2017/09/autoplay-policy-changes
[2] https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Follow up on clang-format

[Chris Pearce]

On Thursday, September 28, 2017 at 10:15:05 AM UTC+2, Chris Pearce wrote:
> On Friday, May 23, 2014 at 3:29:48 AM UTC+2, Anthony Jones wrote:
> > Some of you may remember the discussion on clang-format and the `mach
> > clang-format` command. What we have in place right now is very temporary
> > but it is functional enough to give it a try. I have not put the effort
> > into upstreaming my changes. Depending on the feedback I receive I will
> > either:
> > 
> > * Finish my existing changes and upstream them
> > * Remove the `mach clang-format` command altogether
> > * Do nothing
> > 
> > I have personally found it useful. However I would like to hear from
> > other people who have tried it to help me decide what to do next.
> > 
> > Anthony
> 
> I use `./mach clang-format` on basically every patch I write. It has 
> eliminated the style nits that get picked up when people review my patches, 
> at least when I remember to run it!
> 
> I've considered writing a commit hook to run `./mach clang-format` before 
> every commit, but haven't gotten around to it...
> 
> `mach clang-format` is awesome, please don't remove it.
> 
> As others have pointed out, it doesn't always produce nice formatting, but 
> it's at least consistent, and enforces the major style guide recommendations.
> 
> It's also liberating not having to waste brain power deciding how to format 
> code.
> 
> 
> cpearce.

Oh d'oh! Looks like I replied to an old thread, and the plan now is in fact to 
clang-format the entire tree after 57. Sweet as!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Follow up on clang-format

[Chris Pearce]

On Friday, May 23, 2014 at 3:29:48 AM UTC+2, Anthony Jones wrote:
> Some of you may remember the discussion on clang-format and the `mach
> clang-format` command. What we have in place right now is very temporary
> but it is functional enough to give it a try. I have not put the effort
> into upstreaming my changes. Depending on the feedback I receive I will
> either:
> 
> * Finish my existing changes and upstream them
> * Remove the `mach clang-format` command altogether
> * Do nothing
> 
> I have personally found it useful. However I would like to hear from
> other people who have tried it to help me decide what to do next.
> 
> Anthony

I use `./mach clang-format` on basically every patch I write. It has eliminated 
the style nits that get picked up when people review my patches, at least when 
I remember to run it!

I've considered writing a commit hook to run `./mach clang-format` before every 
commit, but haven't gotten around to it...

`mach clang-format` is awesome, please don't remove it.

As others have pointed out, it doesn't always produce nice formatting, but it's 
at least consistent, and enforces the major style guide recommendations.

It's also liberating not having to waste brain power deciding how to format 
code.


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

Intent to remove: EME support on insecure contexts

[Chris Pearce]

Summary:
Encrypted Media Extensions on insecure contexts (i.e. web sites served over 
non-HTTPS) is deprecated and will soon stop working in Firefox.

Sites wanting to use EME should switch to HTTPS if they have not already.

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

Link to standard:
https://www.w3.org/TR/encrypted-media/#privacy-secureorigin

The EME spec requires that EME only be usable from a secure context, e.g., on 
origins served over HTTPS, and not those served over HTTP.

EME is a powerful feature which makes use of sandboxed closed source CDMs which 
send messages (relayed via the JavaScript video player) to third party servers, 
and the risks are greater if the transport is not encrypted.

Chrome has already removed support for EME on insecure origins in M58:
https://www.chromestatus.com/feature/5724389932793856

Firefox is already logging a deprecation warning to the WebConsole when EME is 
used on an insecure origin (bug 1361000), and we have telemetry to track 
whether EME requests are made in a secure or insecure context:
https://mzl.la/2hsC7Dq

Timeframe:
I am hoping we can remove EME on insecure origins in Q4 2017 or Q1 2018.

Our telemetry shows about 8% of sites using EME are still in insecure contexts, 
and I'd prefer to see that number lower before we disable EME in insecure 
contexts. Given that Chrome have already removed their support for EME in 
insecure contexts, I expect this telemetry to show improvement quickly.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Phabricator Update, July 2017

[Chris Pearce]

What is the status of push-to-review support?

Chris.




On Wednesday, July 12, 2017 at 8:42:06 AM UTC+12, Mark Côté wrote:
> Hi all, here's a brief update on the project to deploy and integrate 
> Phabricator at Mozilla:
> 
> * Development Phabricator instance is up at
> https://mozphab.dev.mozaws.net/, authenticated via
> bugzilla-dev.allizom.org.
> 
> * Development, read-only UI for Lando (the new automatic-landing
> service) has been deployed.
> 
> * Work is proceeding on matching viewing restrictions on Phabricator
> revisions (review requests) to associated confidential bugs.
> 
> * Work is proceeding on the internals of Lando to land Phabricator
> revisions to the autoland Mercurial branch.
> 
> * Pre-release of Phabricator, without Lando, targeted for mid-August.
> 
> * General release of Phabricator and Lando targeted for late September 
> or early October.
> 
> * MozReview and Splinter turned off in early December.
> 
> I have a blog post up with many more details: 
> https://mrcote.info/blog/2017/07/11/phabricator-update/
> 
> More to come!
> 
> Mark
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

[Chris Pearce]

On Monday, July 10, 2017 at 3:28:07 PM UTC+12, Randell Jesup wrote:
> >On Fri, Jul 7, 2017 at 11:54 AM, Jet Villegas  wrote:
> >
> >> What do we expect to break?
> >
> >
> >I can see that video quality auto adjusment which is based on these APIs
> >will become malfunction. But, I don't know is this a real use case that a
> >website implement video quality adjusment based on these APIs.
> 
> This will break a number of our internal mochitests.  I'm not sure
> without some checking if the standardized properties can replace them (I
> think the answer is no in some cases).  We could put them behind a pref
> for testing use.
> 
> >
> >> Who's out there using these APIs now?
> >>
> >
> 
> I do believe a number of webrtc services may use these; it's hard to be
> sure because many of them are not easily findable by searching github
> or search engines.
> 
> >There are some addons using these APIs to report media statistics. For our
> >internal use, there are only some test code using them. And I think the
> >VideoPlaybackQuality can be used to replace them since it provides a
> >similar feature.
> 
> In webrtc and related use, quality is not what these measure; we want to
> know if frames have arrived or been painted (generally using
> mozPaintedFrames).  There is one test using mozParsedFrames.
> 
> Before landing any deprecation warnings, you should check with the
> media/webrtc teams, and we may want to check how one or two external
> users are using it.
> 
> -- 
> Randell Jesup, Mozilla Corp
> remove "news" for personal email


I added these stats originally, and they are now mostly superseded by the stats 
provided by VideoPlaybackQuality. So I support their removal (in fact I 
suggested to Tim that he remove them).

Adding telemetry to learn how often these stats are used in the wild seems like 
a good idea. I'd be surprised if these are still used, but I'm happy to be 
proved wrong!

Randall: doesn't VideoPlaybackQuality support the use cases you're concerned 
about?



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

Re: Start logging at runtime (Firefox 52)

[Chris Pearce]

On Wednesday, May 24, 2017 at 2:22:49 AM UTC+12, Valentin Gosu wrote:
> I think the you can get around the issue by setting the
> security.sandbox.content.level pref to 0 while you're debugging.
> 
> On 23 May 2017 at 08:32, Shih-Chiang Chien <sch...@mozilla.com> wrote:
> 
> > Which platform you're using? For windows it seems to be solved by
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1320458, however other
> > platforms are not fixed yet.
> >
> >
> > Best Regards,
> > Shih-Chiang Chien
> > Mozilla Taiwan
> >
> > On Tue, May 23, 2017 at 11:59 AM, Chris Pearce <cpea...@mozilla.com>
> > wrote:
> >
> > > On Sunday, November 27, 2016 at 5:59:27 AM UTC+13, Valentin Gosu wrote:
> > > > Hi everyone,
> > > >
> > > > (I meant to send this mail a few weeks ago but forgot it in my Drafts
> > > > folder.)
> > > >
> > > > With the landing of Bug 1303762 (Firefox 52), we now have a way for
> > users
> > > > to enable logging without restarting the browser, and without having to
> > > > know what an environment variable is.
> > > >
> > > > We've added a new Logging section to about:networking. When a user
> > > > encounters a bug, all they have to do is open that page, click on
> > "Start
> > > > Logging", reproduce the bug, then click on "Stop Logging" and upload
> > the
> > > > logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG env
> > > > variables have been defined.
> > > > The log modules are automatically set to the most common networking
> > > > modules, but you may instruct the bug reporters to change them - just
> > > tell
> > > > them the string.
> > > >
> > > > This is very useful for bugs that are harder to reproduce once you
> > > restart
> > > > the browser.
> > > >
> > > > There are a bunch of improvements that we could make to the UI, so
> > please
> > > > feel free to send me your feedback and patches. Many thanks to Honza
> > > > Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that
> > helped
> > > > with the implementation and review of this bug and its dependencies.
> > > >
> > > > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/
> > > HTTP_logging?document_saved=true#Using_aboutnetworking
> > >
> > > This seems super handy, but I tried it out and it seems to only affect
> > the
> > > parent process, and not the sub-processes of Firefox?
> > >
> > > ___
> > > 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
> >

I'm using Firefox 54b10 32bit on Windows 10 x64.

Changing the sandbox pref worked, though it required a restart.

Has anyone thought of routing MOZ_LOGs to the Browser Console? How hard would 
that be?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Start logging at runtime (Firefox 52)

[Chris Pearce]

On Sunday, November 27, 2016 at 5:59:27 AM UTC+13, Valentin Gosu wrote:
> Hi everyone,
> 
> (I meant to send this mail a few weeks ago but forgot it in my Drafts
> folder.)
> 
> With the landing of Bug 1303762 (Firefox 52), we now have a way for users
> to enable logging without restarting the browser, and without having to
> know what an environment variable is.
> 
> We've added a new Logging section to about:networking. When a user
> encounters a bug, all they have to do is open that page, click on "Start
> Logging", reproduce the bug, then click on "Stop Logging" and upload the
> logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG env
> variables have been defined.
> The log modules are automatically set to the most common networking
> modules, but you may instruct the bug reporters to change them - just tell
> them the string.
> 
> This is very useful for bugs that are harder to reproduce once you restart
> the browser.
> 
> There are a bunch of improvements that we could make to the UI, so please
> feel free to send me your feedback and patches. Many thanks to Honza
> Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that helped
> with the implementation and review of this bug and its dependencies.
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging?document_saved=true#Using_aboutnetworking

This seems super handy, but I tried it out and it seems to only affect the 
parent process, and not the sub-processes of Firefox?

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

Intent to remove: Insecure use of Encrypted Media Extensions

[Chris Pearce]

Summary: The EME spec [1] states that EME should only be usable from a secure 
origin (i.e. on a domain being served over HTTPS). Currently Gecko's 
implementation works on insecure origins (i.e. sites served over unencrypted 
HTTP). To bring our implementation in line with the spec, we're going to remove 
support for EME on non-secure origins.

Sites using EME that are not using secure origins should switch to HTTPS as 
soon as possible.

Chrome has just removed support for insecure EME in Chrome 58, their most 
recent release.

Motivation: EME makes use of proprietary CDMs that have access to persistent 
storage and that may transmit identifiers to DRM license servers. Requiring 
secure origin and transport makes it harder for the CDM to be attacked by 
others on the channel.

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

Standard: https://www.w3.org/TR/encrypted-media/

Platform coverage: This will affect everywhere that we support EME; Windows, 
MacOS, Linux, Android.

Estimated target date: TBD. Hopefully we can ship this by the end of 2017.

Our telemetry [2] indicates that about 18% of EME use is still on insecure 
origins. We're shipping a deprecation warning in the WebConsole in Firefox 55, 
and given that Chrome have removed this in their latest release I expect we 
should see migration of sites using EME to HTTPS. Once our telemetry indicates 
that use of EME on insecure origins is sufficiently rare, we will go ahead and 
remove support for EME on insecure origins.


[1] https://www.w3.org/TR/encrypted-media/#privacy-secureorigin
[2] https://mzl.la/2rs9maH
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tier 3 win64 ASan builds on try

[Chris Pearce]

On Friday, April 7, 2017 at 2:11:32 PM UTC+12, Ting-Yu Chou wrote:
> Just a heads up that now we have win64 ASan builds on try. The try format:
> 
>   try: -b o -p win64-asan -u none -t none
> 
> Bug 1347793 is tracking the failed tests on taskcluster, though by now the
> tests
> for normal windows builds are not all green yet and I haven't seen any real
> ASan
> issue.
> 
> I am not sure if js/fuzzing folks are interested, but probably we can try
> to do
> fuzzing for jsshell-asan, on windows. (Wonder do we have automated fuzzing
> tests
> on any infrastructure.)
> 
> Note this is still in tier 3, things can regress easily.
> 
> Ting

Awesome!

Is there a wiki page detailing how to setup a Win64 ASAN build locally?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: support ::cue pseudo-element from document.

[Chris Pearce]

On Wednesday, March 29, 2017 at 11:21:06 PM UTC+13, bec...@mozilla.com wrote:
> Summary:
> We are going to support ::cue(with no argument) pseudo-element for webvtt.
> It allows styling the webvtt subtitle/caption text during video playback.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1318542
> 
> Spec: https://w3c.github.io/webvtt/#the-cue-pseudo-element
> 
> Platform coverage:
> All platforms
> 
> Estimated or target release:
> Firefox 55
> 
> Preference:
> media.webvtt.pseudo.enabled, default is true.
> 
> DevTools bug:
> None.
> 
> Do other browser engines implement this?
> Yes, chrome, safari, opera
> 
> Web Developer Use-Cases:
> write the ::cue style block in the document, then ::cue rules will be applied 
> to the .vtt subtitle. Note that the ::cue style block can only appear in 
> document, not in vtt file (not support yet).
> 
> ::cue {
>   ...
> }
> 
> 
>  
> 
> 
> Tests:
> web-platform/tests/webvtt/rendering/cues-with-video/processing-model/selectors/*
> Tests under the folder are disabled now, I'm going to enable/fix them.

Excellent. Thanks Benjamin!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: e10s-multi update and tests

[Chris Pearce]

On Thursday, March 23, 2017 at 2:37:18 PM UTC+13, Nicholas Nethercote wrote:
> On Thu, Mar 23, 2017 at 12:12 PM, Andrew McCreight
> wrote:
> 
> >
> > Though maybe you are asking which processes count against the limit of 4.
> >
> 
> Yes, that's what I am asking.
> 
> Nick

I think there's only one GPU process active at once.

GMP processes are not a content process, and should not count towards the 
content process limit.

At this stage I don't think we need to put a limit on how many GMP processes 
are active at once. All WebRTC's use of GMP shares a single GMP process. We do 
create a new GMP process for every origin doing EME, but in typical usage 
patterns I'd not expect many origins using EME concurrently. GMP processes also 
typically don't use more than 10MB of memory. So I don't think GMP processes 
will be an issue.

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

Re: Project Stockwell (reducing intermittents) - March 2017 update

[Chris Pearce]

I recommend that instead of classifying intermittents as tests which fail > 30 
times per week, to instead classify tests that fail more than some threshold 
percent as intermittent. Otherwise on a week with lots of checkins, a test 
which isn't actually a problem could clear the threshold and cause unnecessary 
work for orange triage people and developers alike.

The currently published threshold is 8%:

https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy#Identifying_problematic_tests

8% seems reasonable to me.

Also, whenever a test is disabled, not only should a bug be filed, but please 
_please_ need-info the test owner or at least someone on the affected team.

If a test for a feature is disabled without the maintainer of that feature 
knowing, then we are flying blind and we are putting the quality of our product 
at risk.


cpearce.



On Wednesday, March 8, 2017 at 9:06:46 AM UTC+13, jma...@mozilla.com wrote:
> On Tuesday, March 7, 2017 at 2:57:21 PM UTC-5, Steve Fink wrote:
> > On 03/07/2017 11:34 AM, Joel Maher wrote:
> > > Good suggestion here- I have seen so many cases where a simple
> > > fix/disabled/unknown/needswork just do not describe it.  Let me work on a
> > > few new tags given that we have 248 bugs to date.
> > >
> > > I am thinking maybe [stockwell turnedoff] - where the job is turned off- 
> > > we
> > > could also ensure one of the last comments indicates this.
> > >
> > > also [stockwell fix] -> [stockwell testfix], [stockwell bandaid] (for 
> > > those
> > > requestLongerTimeouts(), etc.), [stockwell productfix], and [stockwell
> > > reneabled].
> > 
> > Forgive the bikeshedding, but my kneejerk reaction to these is to wonder 
> > whether it's a good idea to use the "stockwell" jargon. It would be a 
> > lot easier for people unfamiliar with the stockwell project if these 
> > were [intermittent turnedoff], [intermittent fix], etc. Perhaps it's too 
> > late, but is that a possibility?
> 
> I think that is valid, thanks for bringing that up!

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

Re: All the processes

[Chris Pearce]

We also have the Gecko Media Plugin process type. It's not the same as Flash 
plugin process. There are at least one per origin doing EME and one shared by 
all users of WebRTC that need to encode/decode H.264.

The media playback team are also working on moving the code that interacts with 
the platforms' audio subsystem into its own process, but that project has only 
recently started.

cpearce.



On Saturday, March 4, 2017 at 1:16:00 PM UTC+13, Nicholas Nethercote wrote:
> Hi,
> 
> I want to understand all the different processes that we can and will have
> in Firefox. Here's a list I constructed off the top of my head.
> 
> - main process
> 
> - content process(es): 1 on release for most users; 2 on Nightly
> 
> - plugin process: just for Flash now?
> 
> - gfx compositor process (bug 1264543, in Fx53)
> 
> - file:// URL access process (bug 1147911, in Fx53)
> 
> IIRC there was a proposal for a thumbnail generation process a while back
> but judging by bug 1187441 that was scrapped.
> 
> Do I have any of these details wrong? Have I missed any?
> 
> Thanks.
> 
> Nick

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

Re: Removing navigator.buildID?

[Chris Pearce]

It's not just Netflix that the media playback team has used 
navigator.buildID in order to validate fixes; we've used it with other 
large video sites too. It's invaluable for determining whether a bug has 
been fixed in a build. Can we only disable navigator.buildID in release 
builds? Don't users on pre-release versions of Firefox update more 
often, and thus the buildID changes too rapidly to be useful?


cpearce.

On 11/1/2016 7:01 AM, Domenic Denicola wrote:

On Monday, October 31, 2016 at 10:54:11 AM UTC-4, Mike Taylor wrote:

On 10/31/16 9:16 AM, Henri Sivonen wrote:

On Oct 31, 2016 16:02, "Mike Taylor" > wrote:



On 10/29/16 9:21 AM, Kohei Yoshino wrote:

I think now is a good time to think about navigator.buildID again
Thoughts?


Seems like we'd potentially end up breaking legacy sites that sniff

that to mean "isMozilla".
I suggest returning a constant value to general Web sites to avoid this
problem.

I think that's a good path forward.

--
Mike Taylor
Web Compat, Mozilla

If Gecko has no plans to remove this and conform to the spec, could someone 
file an issue or pull request on https://github.com/whatwg/html requesting that 
buildID be added to Gecko compatibility mode? 
https://html.spec.whatwg.org/multipage/#concept-navigator-compatibility-mode


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

Re: Faster gecko builds with IceCC on Mac and Linux

[Chris Pearce]

It would be cool if, once distributed compilation is reliable, if `./mach 
mercurial-setup` could 1. prompt you enable using the local network's 
infrastructure for compilation, and 2. prompt you to enable sharing your CPUs 
with the local network for compilation.

Distributing a Windows-friendly version inside the MozillaBuild package would 
be nice too.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

[Chris Pearce]

On Friday, June 3, 2016 at 9:51:58 AM UTC+12, Eric Shepherd wrote:
> Do: do you want this method documented or not? I presume not, since
> exposure will be limited.
> 
> ----
> *From:* Chris Pearce
> *Sent:* Thursday, Jun 2, 2016 4:40:59 PM EDT
> *To:* dev-platform@lists.mozilla.org
> *Subject:* Intent to implement: HTMLMediaElement::seekToNextFrame()
> 
> > We're not going to ship the API enabled in the current form in Release 
> > Firefox.
> 
> -- 
> 
> Eric Shepherd
> Senior Technical Writer
> Mozilla Developer Network <https://developer.mozilla.org/>
> Blog: https://www.bitstampede.com/
> Twitter: http://twitter.com/sheppy
> Doodle: http://doodle.com/the.sheppy


I think minimal documentation, saying that this feature is experimental and 
that the user must enable the pref before it'll work is useful.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

[Chris Pearce]

On Thursday, June 2, 2016 at 9:34:25 AM UTC+12, Jet Villegas wrote:
> On Thu, May 26, 2016 at 7:49 PM, Tzu-Hao Kuo  wrote:
> 
> 
> > *Link to standard*: No standard. This API was first discussed at Mozlando
> > and has been discussed online here(
> > https://github.com/w3c/mediacapture-worker/issues/33). The discussion has
> > been led to a stream-based design which will probably take a long time so
> > we would like to implement the proposed HTMLMediaElement::seekToNextFrame()
> > first for testing.
> >
> 
>  What's the plan for resolving Streams/MediaStream integration raised on
> the github issue? I read "probably take a long time" to mean we're working
> on it, but is that actually the case? This is a feature we definitely want
> interop on.
> 
> --Jet



The plan is to use feedback garnered from people experimenting with the 
experimental API in pre-release builds to help guide the design of the larger 
streams-based API.

We're not going to ship the API enabled in the current form in Release Firefox.

There are guys in Taipei interested in working on a streams-based API I 
believe. So they'll likely be leading the effort. We'll discuss this at 
Mozlondon.
___
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

[Chris Pearce]

So, given that users won't be able to install Firefox on unsupported
versions of MacOSX, and unsupported users won't be upgraded, can we proceed
to remove all the nsCocoaFeatures::On[Mountain]LionOrLater() calls in
Firefox 49 and just assume everywhere that MacOSX specific Gecko code is
running on 10.9 or later?



On Fri, May 27, 2016 at 4:59 PM, Ralph Giles  wrote:

> On Thu, May 26, 2016 at 3:37 PM, L. David Baron  wrote:
>
> > There's a screenshot in:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
> > (which is the bug that made the necessary changes for the Mac OS X
> > support change in Firefox 49).
>
> Ah, that's great. Thanks!
>
>  -r
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Generating Visual Studio project files by default

[Chris Pearce]

Awesome. Using the VisualStudio project file makes me significantly more 
productive, so I recommend everyone on Windows use it for debugging, learning 
about, and editing code.

The experience is significantly better if you install the Visual Assist plugin 
by Whole Tomato Software:
http://www.wholetomato.com/

This makes VisualStudio's IntelliSense perform significantly better, i.e. less 
crashy; you don't have to roll the dice every time you jump-to-definition on a 
symbol. It also adds ALT+SHIFT+O to open file in project, and ALT+SHIFT+S to 
search for symbol, which also perform significantly faster than VisualStudio's 
built-in equivalent feature (CTRL+,).

Install it. They have a free trial, and once that expires, get Mozilla to pay 
for a license. You'll be more productive because of it. It's worth it.


cpearce.





On Wednesday, May 25, 2016 at 11:00:48 AM UTC+12, Gregory Szorc wrote:
> Coming soon to your local builds, Visual Studio project files will be
> generated automatically when building on Windows because we want to
> encourage more people to use them because fully-featured IDEs can be
> productivity wins.
> 
> The Visual Studio projects now automatically target the Visual Studio
> version being used (1 week ago they would always generate VS2013 project
> files). Another new change is that unless the build configuration changes,
> the Visual Studio files won't be updated by the build system unless they
> need changed. That means if you do a pull+build when Visual Studio is open,
> you shouldn't get tons of warnings that you need to reload files to pick up
> changes.
> 
> The Visual Studio integration isn't perfect. We'd like to encourage more
> development on Windows because that's where most Firefox users are. So if
> you'd like improvements to the Visual Studio project files, please file
> Core :: Build Config bugs.
> 
> This change was tracked in bug 1275297. Bug 1275419 tracks a follow-up to
> allow disabling their generation.

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

Re: Tech talk tomorrow: Windows GUI, COM, and IPC: Oh my!

[Chris Pearce]

That's 5AM Saturday for me, so I'd love to see the recording!

cpearce.


On 9/25/2015 7:15 AM, Aaron Klotz wrote:

In case anybody is interested:

I'm going to be doing a tech talk tomorrow about the challenges of 
combining Windows GUI, Microsoft COM, and IPC in our code. It'll start 
with a history lesson on the Windows GUI, some Microsoft COM 
essentials, and then I'll demonstrate how these topics interleave into 
a giant hairball that some of us deal with on a daily basis.


If you regularly work with one or more of these APIs, this talk may be 
useful to you.


10AM Pacific, 1PM Eastern, my Vidyo room.

I'll try to record it for later viewing.

Aaron


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

Re: New policy: 48-hour backouts for major Talos regressions

[Chris Pearce]

We recently had a false positive Talos regression on our team, which 
turned out to be caused by a change to the test machine coinciding with 
our push. This took up a bunch of energy and time away from our team, 
which we really can't afford.


So to mitigate that I propose that *before* the backout happens, someone 
on the regression-detection team does an `hg up` and Try push of the 
backout and a Try push without the backout to ensure that backing out 
actually helps.


Retriggers on the original push in our case didn't help, so I think a 
completely clean push is necessary.


This should also assist the regression-detection team in convincing 
patch authors that their patch is at fault.


The Try-backout should happen before the need-info to the patch author 
happens. If the backout has non-trivial merge conflicts, then the first 
action of the patch author should be to preform this step instead of the 
regression-detection team member.


cpearce.


On 8/15/2015 1:02 PM, Vladan Djeric wrote:

There are known issues with the test infrastructure (e.g. differences in
weekend vs weekday results) and those known issues are currently being
masked with human judgement.
A-Team has investigated these issues, and fixed some of them, but fixing
the rest will take a non-trivial amount of effort as I understand it.
When there's enough time to fix all the sources of noise in the
infrastructure, human judgement will no longer be required.

As an aside, I'm answering the questions for this 48-hour backout
announcement, but it's really Joel Maher + William Lachance + Vaibhav
Agarwal doing all the heavy lifting related to regression handling. They're
working on the regression-detection and regression-investigation tools, and
they're the ones acting as perf sheriffs.

Avi from my team is helping test the tools, and I just participate in
policy discussions and act as an (unintentional) spokesperson :)

On Fri, Aug 14, 2015 at 8:49 PM, Martin Thomson m...@mozilla.com wrote:


On Fri, Aug 14, 2015 at 3:44 PM, Vladan Djeric vdje...@mozilla.com
wrote:

Is this the ts_paint regression you're referring to?


https://groups.google.com/forum/#!searchin/mozilla.dev.tree-alerts/ts_paint/mozilla.dev.tree-alerts/FArVsa8guXg/FfY91JK7AAAJ

Yeah.  I only ask because in exercising judgment suppresses
information about the stability of the tests, so that all we have is
anectodal evidence.  That's probably OK here.  The process you
describe sounds pretty robust against false positives.



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

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

[Chris Pearce]

On 7/15/2015 3:23 AM, Benjamin Smedberg wrote:


Given that premise, we shouldn't just change aArgument; we should 
adopt the Google C++ style guide wholesale:


* names_with_underscores
* members_with_trailing_
* no more ns prefix



I used this style in a personal project, and I quickly came to regret it.

Distinguishing whether a variable is a member verses being a local var 
by a single '_' character I found was harder, as '_' is a very small 
character, and is hard to see, especially when syntax highlighting is 
underlining the word. Whereas the difference between a leading 'a' and 
'm' is very obvious, even when syntax highlighting is underlining the word.


I think adopting Google style is a bad idea.

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

Re: Replacing PR_LOG levels

[Chris Pearce]

My team has been trying (and failing!) for years to get a Verbose level 
added to NSPR logging.


In the (non-WebRTC) media playback code, we now use the PR_LOG_DEBUG+1 
hack. Like WebRTC, we have spammy, and super spammy logging modes. 
Because of threading, often logging is the only or easiest way to debug 
things.


We've previously used an environment variable to toggle on verbose 
logging, and previously also tried using separate log modules for 
logging, and in the end we went with the PR_LOG_DEBUG+1 hack to get what 
we want.


We really don't want a custom way to turn on verbose logging, our 
logging system should support what we want.



On 5/23/2015 9:53 AM, Eric Rahm wrote:

Thanks Adam, these are good points.

On Friday, May 22, 2015 at 2:08:33 PM UTC-7, Adam Roach wrote:

On 5/22/15 15:51, Eric Rahm wrote:

I agree, we shouldn't make it harder to turn on logging. The easy solution is 
just to add a separate logger for verbose messages (if we choose not to add 
Verbose/Trace).

I don't know why we wouldn't just add a more verbose log level (Verbose,
Trace... I don't care what we call it). The presence of DEBUG + 1 in
our code is evidence of a clear, actual need.

This was my thought as well initially (my first proposal had a Verbose level). 
After auditing the code I changed my mind.

I believe adding the Info level will serve this need.


I feel that using Info to denote debug messages and Debug to 
denote verbose messages is semantically *not* what we want.


If you're convinced that we can get by with 5 log levels, why not delete 
the Info category and add a Verbose mode as greater than Debug ? 
Then my team will get semantically what we want; we don't use Info as 
it's not semantically what we want.



Cheers,
Chris Pearce.

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

Re: Replacing PR_LOG levels

[Chris Pearce]

On 5/27/2015 3:58 PM, Randell Jesup wrote:

Thanks Randell, these are good points. I'll address a few of your comments
that have not already been covered in the rest of the conversation.


This is used extensively in WebRTC and related media bits to enable
*huge* amounts of debugs (like every-frame debugs for audio or video or
per-network-packet debugs, which will swamp a system normally), and since
people are used to enabling debug on random modules (or all:5), having
verbose debugs in the normal :5 setting will cause pain.


Here lies half the problem, that number does not mean what we were led to
think it means. Using :5 would include PR_LOG_DEBUG + 1 [1].


The above will also be surprising since it will work differently than
other modules, making the same sorts of debugs appear at different
levels.  This would be expecially confusing to people not frequently
working in the module or when external users are asked to turn on
debugging.

This assumes log levels have been used consistently across modules, I can
assure you that is not the case :) I hope that we can get to a more
consistent state of course!

Sure - but having debug logs at DEBUG in module A, and INFO in module
B (with verbose-you-only-want-them-if-you-want-insane-data being at
DEBUG in B) will cause confusion.


+1 !!




   It means turn on logging for X
requires knowledge of which of two patterns X follows.  It also
means all:4 (or all:debug) will cause suprising (and useless) results.
And when coding, it'll be easy to use the wrong pattern when switching
between modules.  I see serious pain in a two-model system.  And we have
real *need* for logging at a makes-the-browser-almost-unusable volume to
track down certain sorts of things.

Even splitting say mediamanager:5 into mediamanager:4 (or :debug) and
mediamanager_verbose:4 (or :debug) will have the same problem for all:.
And it will make getting verbose logging more painful for no real reason.


I don't think it will be any more confusing when telling the external user
what level to turn on (it's already rather confusing). Do we need super
spammy? Turn on debug. Do we need just the basics? Turn on info.


Then there's an oddball: webrtc.org Trace logging (a separate
subsystem with low-overhead buffered-IO circular-log maxed at 10MB),
which requires a 16-bit mask.  Currently this is exposed as
webrtc_trace:65535 (for example), with a separate env var telling it
where to put the logfile (or 'nspr' to revector the logs through NSPR
logging, which *really* will cause problems with realtime code but is
handy at times).  For this oddball, we could do other things like move
it to a separate env var (which is annoying to people using it, but not
horribly).

I think it's probably best to keep this a separate env rather than trying to 
shoehorn it in.

Understandable - but I've been trying to move in the opposite direction;
avoiding N different env vars (and also, if I can avoid that, I have
a better chance of leveraging on-the-fly log level changes without
having to reinvent the wheel).



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

Re: Replacing PR_LOG levels

[Chris Pearce]

Yes, thanks. Eric's message was scrolled out of my view when I wrote my 
responses. I'm happy to hear that.


cpearce.

On 5/29/2015 1:42 PM, Nicholas Nethercote wrote:

On Thu, May 28, 2015 at 4:21 PM, Chris Pearce cpea...@mozilla.com wrote:

My team has been trying (and failing!) for years to get a Verbose level
added to NSPR logging.

Just yesterday Eric wrote (in the message immediately before this one
in the thread) the following:


After some back and forth in this thread, IRC, and in bugzilla I've been 
convinced that adding
a Verbose level will make this transition smoother.

No need to keep arguing.

Nick


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

Re: Mozillabuild 2.0 ready for testing

[Chris Pearce]

Ah yes, I installed it to a patch with a space in it. Thanks!

cpearce.

On Thu, Mar 12, 2015 at 8:28 AM, Ryan VanderMeulen 
rvandermeu...@mozilla.com wrote:

 More context would be helpful. I personally run it out of
 c:\mozilla-build-test without issues. Are you using spaces in the path by
 chance?

 On Wed, Mar 11, 2015 at 3:21 PM, Chris Pearce cpea...@mozilla.com wrote:

 If I install this into a directory other than c:\mozilla-build I get an
 error dialog popup saying can't find c:\mozilla-build or somesuch. Maybe
 there's a path hardcoded somewhere? It's a bit of a footgun since the
 installer defaults to a non c:\mozilla-build install dir.

 Thanks very much for making bzexport work!

 cpearce.




 On 3/9/2015 2:44 PM, Ryan VanderMeulen wrote:

 For the past many months, I have been working on some major updates to
 the
 Mozillabuild package in order to make it more developer-friendly and
 easily-maintainable in the future. I am proud to say that at this time,
 it
 is ready for more widespread testing.

 The latest test build can be downloaded from the link below:
 http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.0.0pre4.exe
 sha1sum: 9edb5c51bdb5f9a5d86baf5046967d8940654353

 Release notes are available below. A few general notes:
 * It is strongly advised that you *NOT* install this over a previous 1.x
 install. Changes have been made to the directory structure and underlying
 packages that could result in unexpected results should you choose to do
 so.
 * As is always the case when updating Mozillabuild, you should clobber
 after installing.
 * Bugs that you come across can be filed in the mozilla.org:
 :MozillaBuild
 component.

 My goal is to ship the final release in two weeks, so any feedback you
 can
 provide now would be welcome!

 Thanks,
 Ryan

 -

 SIGNIFICANT CHANGES
 * Added support for MSVC2015 and dropped support for MSVC 2013, WinSDK
 8.1, and MSVC Express Edition.
- MSVC Community Edition is now the recommended free compiler option
 * Added minTTY 1.1.3 and enabled it as the default console.
- Windows cmd.exe can be used by default by removing the 1 from |SET
 USE_MINTTY=1| near the top of start-shell.bat
 * Overhauls to the start-msvc* batch scripts that improve consistency and
 simplify maintenance.
- To launch a plain terminal with no MSVC path setting, use
 start-shell.bat (was start-shell-l10n.bat in previous releases)
 * Updated Mercurial to version 3.3.2 and switched to the native python
 version.
- Allows extensions like bzexport that rely on previously-unavailable
 python components to work correctly.
- Enables faster future updates in the event of serious bugs or
 security
 issues.
- Enabled extensions: blackbox, color, histedit, mq, pager, progress,
 purge, rebase, share, transplant
- See the Known Issues section for regressions from this change.
 * Updated python to version 2.7.9.
- Included packages: pip 6.0.8, setuptools 14.0, virtualenv 12.0.7

 OTHER UPDATES/ADDITIONS/REMOVALS
 * Removed SVN
 * Updated 7-zip to version 9.20
 * Updated bundled CA certs to those from NSS 3.17.4
 * Updated emacs to version 24.4
 * Updated MSYS to version 1.0.18 and various components to the latest
 available for MSYS1
 * Updated wget to version 1.16.1

 KNOWN ISSUES
 * Changes in behavior due to using minTTY instead of Windows cmd.exe
 * Problems with python scripts that can't find an hg executable in the
 path
 (bug 1128586, bug 1131048)




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

Re: Mozillabuild 2.0 ready for testing

[Chris Pearce]

If I install this into a directory other than c:\mozilla-build I get an 
error dialog popup saying can't find c:\mozilla-build or somesuch. Maybe 
there's a path hardcoded somewhere? It's a bit of a footgun since the 
installer defaults to a non c:\mozilla-build install dir.


Thanks very much for making bzexport work!

cpearce.



On 3/9/2015 2:44 PM, Ryan VanderMeulen wrote:

For the past many months, I have been working on some major updates to the
Mozillabuild package in order to make it more developer-friendly and
easily-maintainable in the future. I am proud to say that at this time, it
is ready for more widespread testing.

The latest test build can be downloaded from the link below:
http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.0.0pre4.exe
sha1sum: 9edb5c51bdb5f9a5d86baf5046967d8940654353

Release notes are available below. A few general notes:
* It is strongly advised that you *NOT* install this over a previous 1.x
install. Changes have been made to the directory structure and underlying
packages that could result in unexpected results should you choose to do so.
* As is always the case when updating Mozillabuild, you should clobber
after installing.
* Bugs that you come across can be filed in the mozilla.org::MozillaBuild
component.

My goal is to ship the final release in two weeks, so any feedback you can
provide now would be welcome!

Thanks,
Ryan

-

SIGNIFICANT CHANGES
* Added support for MSVC2015 and dropped support for MSVC 2013, WinSDK
8.1, and MSVC Express Edition.
   - MSVC Community Edition is now the recommended free compiler option
* Added minTTY 1.1.3 and enabled it as the default console.
   - Windows cmd.exe can be used by default by removing the 1 from |SET
USE_MINTTY=1| near the top of start-shell.bat
* Overhauls to the start-msvc* batch scripts that improve consistency and
simplify maintenance.
   - To launch a plain terminal with no MSVC path setting, use
start-shell.bat (was start-shell-l10n.bat in previous releases)
* Updated Mercurial to version 3.3.2 and switched to the native python
version.
   - Allows extensions like bzexport that rely on previously-unavailable
python components to work correctly.
   - Enables faster future updates in the event of serious bugs or security
issues.
   - Enabled extensions: blackbox, color, histedit, mq, pager, progress,
purge, rebase, share, transplant
   - See the Known Issues section for regressions from this change.
* Updated python to version 2.7.9.
   - Included packages: pip 6.0.8, setuptools 14.0, virtualenv 12.0.7

OTHER UPDATES/ADDITIONS/REMOVALS
* Removed SVN
* Updated 7-zip to version 9.20
* Updated bundled CA certs to those from NSS 3.17.4
* Updated emacs to version 24.4
* Updated MSYS to version 1.0.18 and various components to the latest
available for MSYS1
* Updated wget to version 1.16.1

KNOWN ISSUES
* Changes in behavior due to using minTTY instead of Windows cmd.exe
* Problems with python scripts that can't find an hg executable in the path
(bug 1128586, bug 1131048)


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

Re: e10s is now enabled by default for Nightly!

[Chris Pearce]

e10s also broke playback of audio streams in MP4 files...

bug 1096717.


Chris P.


On 11/7/2014 1:27 PM, Chris Peterson wrote:
The patch is on mozilla-inbound and ought to hit mozilla-central in 
time for tomorrow's Nightly build. \o/


https://hg.mozilla.org/integration/mozilla-inbound/rev/a75897e664dd

e10s will not ride the trains to Aurora 36. Talos and unit tests will 
continue to run for e10s and non-e10s until e10s hits the Release 
channel.


Some known problems:

* IME and a11y will disable e10s until support is completed
* Some performance problems with Adblock Plus
* Bug  947030 - Ghostery add-on does not block trackers
* Bug  972507 - BugzillaJS add-on does not work [1]
* Bug 1008768 - LastPass add-on does not fill in form fields
* Bug 1014986 - HTTPS Everywhere add-on breaks HTTP redirects
* Bug 1042680 - Tree Style Tabs add-on does not work
* Bug 1042195 - 1Password add-on does not work
* Bug 1058542 - NoScript add-on does not work
* Bug 1093161 - Searching from address bar does not work the first time

If you have any questions, drop by #e10s on IRC. If you file new bugs 
related to e10s, please include the word e10s in the summary so the 
e10s team's triage queries will find your bug.



chris

[1] btw, BugzillaJS is seeking a new maintainer:
https://www.yammer.com/mozillians/#/threads/show?threadId=454089406


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

Re: e10s is now enabled by default for Nightly!

[Chris Pearce]

E10s also breaks EME Gecko Media Plugins, and probably OpenH264 as well.

Bug 1057908 should fix that...


Chris Pearce.




On 11/7/2014 1:27 PM, Chris Peterson wrote:
The patch is on mozilla-inbound and ought to hit mozilla-central in 
time for tomorrow's Nightly build. \o/


https://hg.mozilla.org/integration/mozilla-inbound/rev/a75897e664dd

e10s will not ride the trains to Aurora 36. Talos and unit tests will 
continue to run for e10s and non-e10s until e10s hits the Release 
channel.


Some known problems:

* IME and a11y will disable e10s until support is completed
* Some performance problems with Adblock Plus
* Bug  947030 - Ghostery add-on does not block trackers
* Bug  972507 - BugzillaJS add-on does not work [1]
* Bug 1008768 - LastPass add-on does not fill in form fields
* Bug 1014986 - HTTPS Everywhere add-on breaks HTTP redirects
* Bug 1042680 - Tree Style Tabs add-on does not work
* Bug 1042195 - 1Password add-on does not work
* Bug 1058542 - NoScript add-on does not work
* Bug 1093161 - Searching from address bar does not work the first time

If you have any questions, drop by #e10s on IRC. If you file new bugs 
related to e10s, please include the word e10s in the summary so the 
e10s team's triage queries will find your bug.



chris

[1] btw, BugzillaJS is seeking a new maintainer:
https://www.yammer.com/mozillians/#/threads/show?threadId=454089406


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

Re: fopen, gtest and try

[Chris Pearce]

Another use case here is we want to write GTests to test Gecko Media 
Plugins. These are the plugins we're using for EME and OpenH264 plugins. 
To load them we need to set an environment variable to the path of the 
directory in which the plugin dll resides, or pass that path to the 
plugin to a function. Currently we haven't figured out how to do this, 
for all reasons you outlined already.



Chris P.



On 7/11/2014 12:06 AM, Ted Mielczarek wrote:

On Thu, Jul 10, 2014, at 12:17 AM, Anthony Jones wrote:

I've recently been using gtest for media code. However I've come across
the issue of fopen() working locally but not on the try servers.

https://tbpl.mozilla.org/?tree=Tryrev=11d9f94c54bd

Any suggestions on how I should do this differently?

I'm guessing this is a working directory issue. On Try gtest will be
running as part of make check, so the cwd will be $objdir/testing/gtest:
http://hg.mozilla.org/mozilla-central/annotate/cb75d6cfb004/testing/gtest/Makefile.in#l24

Whereas if you're doing mach gtest it looks like it doesn't change the
cwd so it'll be $topsrcdir:
http://hg.mozilla.org/mozilla-central/annotate/cb75d6cfb004/python/mozbuild/mozbuild/mach_commands.py#l616

If you run ./mach build testing/gtest/check do you get the same
failures locally?

We should make these consistent to avoid this problem. However, note
that relying on external files is going to cause issues in the future,
we should figure out exactly what we want here--we're going to
eventually move gtest out of make check and into the test package, which
means that we'd have to explicitly copy files that tests want to
reference.

-Ted


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

Re: Intent to Implement: Encrypted Media Extensions

[Chris Pearce]

On 5/31/2014 4:44 AM, Gervase Markham wrote:

On 27/05/14 19:44, Chris Pearce wrote:

Encrypted Media Extensions specifies a JavaScript interface for
interacting with plugins that can be used to facilitate playback of DRM
protected media content. We will also be implementing the plugin
interface itself. We will be working in partnership with Adobe who are
developing a compatible DRM plugin; the Adobe Access CDM.

Is now the time to have the UX discussion? If not, when and where will
that be happening?





I think we should have the UX discussion ASAP, so that we can get on 
with implementing it ASAP.


I don't know where we'll be having that discussion, I don't know how the 
UX people and their process works.



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

Intent to Implement: Encrypted Media Extensions

[Chris Pearce]

Summary:

Encrypted Media Extensions specifies a JavaScript interface for 
interacting with plugins that can be used to facilitate playback of DRM 
protected media content. We will also be implementing the plugin 
interface itself. We will be working in partnership with Adobe who are 
developing a compatible DRM plugin; the Adobe Access CDM.


For more details:
https://hsivonen.fi/eme/
https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/
https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/


Bug:

Main tracking bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1015800


Link to standard:

https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html

This spec is being implemented in IE, Safari, and Chrome.
MS and Google are actively participating in the W3C working group; 
public-html-media.

Blink's Intent To Implement: http://bit.ly/1mnELkX


Platform coverage:

Firefox on desktop.


Estimated or target release:

Firefox 36.


Preference behind which this will be implemented:

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

nsRefPtr vs RefPtr

[Chris Pearce]

We have two reference counted smart pointer implementations; nsRefPtr 
and the newer mozilla::RefPtr.


Should we be preferring mozilla::RefPtr in new code?

Should we be replacing nsRefPtr with mozilla::RefPtr?


Cheers,
Chris P.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio Project Generation

[Chris Pearce]

This is awesome! Thank you!

Chris P.


On 2/19/2014 8:28 AM, Gregory Szorc wrote:
The tree (only inbound so far) now has (alpha) support for generating 
Visual Studio Project files.


Features:

* IntelliSense works
* Build from within Visual Studio
* Launch binaries from Visual Studio
* Debug symbols loaded automatically (breakpoints work)

Please read 
https://hg.mozilla.org/integration/mozilla-inbound/file/default/build/docs/visualstudio.rst 
for usage info.


File bugs against Core :: Build Config to request improvements.

Bug 973770 is on file and has a patch to generate Eclipse projects. 
That should hopefully land soon.


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

Re: CPP_UNIT_TESTS being removed from make check

[Chris Pearce]

Is there trychooser syntax for just running the cpp tests on a try push?

And can http://trychooser.pub.build.mozilla.org/ be updated to include 
it please? :)



Cheers,
Chris P.


On 1/9/2014 7:00 AM, Ted Mielczarek wrote:

Hello,

Just a heads up that very soon we'll be removing CPP_UNIT_TESTS from the
make check target[1]. The tests have been split out into a separate
test job on TBPL[2] (labelled Cpp) for almost a month now without issue,
and we've also added a mach command--mach cppunittests[3]--to
facilitate running them locally, so we'd like to stop double-running
them on the build machines.

Running the tests as a separate job has a lot of nice qualities: the
jobs can be retriggered in case of failure, the execution time doesn't
tie up a build slave (and thus delay the posting of the build log by
buildbot to where TBPL can get it), we can run the tests on Android and
B2G, we get better platform coverage on our test slaves than on our
build slaves.

If you encounter any issues please feel free to file a bug.

Regards,
-Ted

1. https://bugzilla.mozilla.org/show_bug.cgi?id=949536
2. https://bugzilla.mozilla.org/show_bug.cgi?id=937637
3. https://bugzilla.mozilla.org/show_bug.cgi?id=949538


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

Can we start using C++ STL containers in Mozilla code?

[Chris Pearce]

Hi All,

Can we start using C++ STL containers like std::set, std::map, 
std::queue in Mozilla code please? Many of the STL containers are more 
convenient to use than our equivalents, and more familiar to new 
contributors.


I understand that we used to have a policy of not using STL in mozilla 
code since some older compilers we wanted to support didn't have very 
good support, but I'd assume that that argument no longer holds since 
already build and ship a bunch of third party code that uses std 
containers (angle, webrtc, chromium IPC, crashreporter), and the sky 
hasn't fallen.


I'm not proposing a mass rewrite converting nsTArray to std::vector, 
just that we allow STL in new code.


Are there valid reasons why should we not allow C++ STL containers in 
Mozilla code?


Cheers,
Chris P.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we start using C++ STL containers in Mozilla code?

[Chris Pearce]

It seems to me that we should be optimizing for developer productivity 
first, and use profiling tools to find code that needs to be optimized.


i.e. we should be able to use STL containers where we need basic ADTs in 
day-to-day coding, and if instances of these containers show up in 
profiles then we should look at moving indivdual instances over to more 
optimized data structures.


On 12/11/2013 4:42 AM, Benjamin Smedberg wrote:

njn already mentioned the memory-reporting issue.


We already have this problem with third party libraries that we use. We 
should work towards having a port of the STL that uses our memory 
reporters, so that we can solve this everywhere, and influence the size 
of generated code for these templates.



Also, some of the containers are not suitable for use in a codebase 
that doesn't allow exceptions. For instance std::map.at() wouldn't be 
appropriate in our code and may not compile.


We compile with -D_HAS_EXCEPTIONS=0 on Windows, so the use of functions 
that throw should be caught at compile time, or at worst cause backouts 
at landing. Won't that prevent us throwing exceptions?



AIUI, the current status of using the C++ standard containers is that 
they aren't necessarily forbidden, but we should be careful about 
checking our assumptions about how they use exceptions, how much they 
cost in codesize, and whether we need to reimplement or subclass them 
in MFBT in order to get better memory reporting.


Based on 
https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code#C.2B.2B_and_Mozilla_standard_libraries 
(thanks njn!) we can use std::unordered_map and std::unordered_set at 
least. That still won't give us a convenient to use queue/deque through.



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

Re: Should we disable autoplay feature of HTMLMediaElement on mobile?

[Chris Pearce]

On 12/11/2013 3:07 PM, Tetsuharu OHZEKI wrote:

2013/12/11 Hubert Figuière h...@mozilla.com:

It should be noted that here on desktop I do have
`media.autoplay.enabled=false` (I hate videos that autoplay) and this
still doesn't stop YouTube. [1]

I seem that Gecko's implementation of HTMLMediaElement.play() doesn't
handle `media.autoplay.enabled`.
http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLMediaElement.cpp#2112




Because play() and autoplay are different.

We could add a pref that caused HTMLMediaElement.play() to only work if 
called from inside a user generated event handler (i.e. mouse click, key 
press). That would achieve most of what you want, and is very easy to 
implement.



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

Re: Should we disable autoplay feature of HTMLMediaElement on mobile?

[Chris Pearce]

On 12/11/2013 4:18 PM, Alex Jordan wrote:

On Dec 10, 2013 6:30 PM, Chris Pearce cpea...@mozilla.com wrote:

We could add a pref that caused HTMLMediaElement.play() to only work if

called from inside a user generated event handler (i.e. mouse click, key
press). That would achieve most of what you want, and is very easy to
implement.
This seems like it might break e.g. games.


This would be preffed *off* by default of course. We could make this 
only for video elements in documents. But that's still defeatable. You 
really want something like what roc suggested. This is just easier.



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

Re: Should we disable autoplay feature of HTMLMediaElement on mobile?

[Chris Pearce]

On 12/10/2013 4:38 AM, Henri Sivonen wrote:

On Sun, Dec 8, 2013 at 11:49 AM, Robert O'Callahan rob...@ocallahan.org wrote:

I think it's important to have an easy way to mute/unmute the browser, but
disabling autoplay is probably not the right way to address these issues.

A pref to disable autoplay might be, though.


We have this, set media.autoplay.enabled to false.

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

Re: Faster builds, now ; on windows, too.

[Chris Pearce]

Thanks for putting this together, and thanks to everybody working on 
making the build faster and thus making us all more productive. This 
sped up clobber build times on Windows for me by 6 minutes, around 22%, 
which is great. Some of us can't switch to a *nix based platform in 
order to get faster builds, so thanks very much.


Cheers,
Chris P.




On 17-Oct-13 2:43 AM, Mike Hommey wrote:

Hi,

Episode 1 was the You want faster builds, don't you thread.
Episode 2 was the Faster builds, now thread.
Here comes episode 3.

I'm sure fellow developers building on Windows felt sad that they were
left out on the recent build improvements. Rejoice at last, as we are
now bringing those to you.

As of current mozilla-inbound, and I'm sure mozilla-central soon, it
only takes a few steps:

- Download the mozmake binary from
   http://people.mozilla.org/~mhommey/mozmake.exe and place it in some
   location in your $PATH. c:\mozilla-build\msys\local\bin is probably
   good for most people. See bug 927213 if you want to know how it was
   built. It will eventually be shipped in next release of MozillaBuild.
- Add the following to your mozconfig:
 export MOZ_PSEUDO_DERECURSE=no-pymake
   (Note this should become the default next week)
- Build with:
 ./mach build

After you built once, you can do edit-compile-edit-compile cycles with:
 ./mach build binaries

Enjoy the faster build times.

Cheers,

Mike

PS: mozmake is also being tested on the birch branch, and it is showing
promising turnaround times on Windows build slaves (-35 minutes on opt
builds, -1 hour on debug builds ; most of which is, surprisingly, is
gained on make check, see
https://bugzilla.mozilla.org/show_bug.cgi?id=925605#c13 )


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

Re: C++ style question: virtual annotations on methods

[Chris Pearce]

On 04-Sep-13 4:18 PM, Robert O'Callahan wrote:

I like to put virtual on all methods that are virtual, even when it's not
strictly necessary because the method overrides a virtual method  of the
parent class.

Other people disagree, especially when the method has MOZ_OVERRIDE on it as
well.


virtual on non-overrides, MOZ_OVERRIDE on overrides. MOZ_OVERRIDE 
implies virtual, you get a compile error when you put MOZ_OVERRIDE on a 
non virtual, so it enforces that you're doing what you think you're 
doing, so we should use it.



Chris P.

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

Re: Do you consider to port mp3 support on Windows XP

[Chris Pearce]

On 8/13/2013 3:08 AM, Ted Mielczarek wrote:

On 8/12/2013 8:35 AM, lchenneb...@gmail.com wrote:

Ok, do you consider to finish it before October?
Is firefox will support Mp4 too?


You can track his progress in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=861693

It looks like those patches are MP3 support only, not h.264.




My patches have landed and stuck.

MP3 support for Windows XP will ship in Firefox 26, unless some problem 
comes up.



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

Re: Do you consider to port mp3 support on Windows XP

[Chris Pearce]

On 7/23/2013 6:52 AM, Ralph Giles wrote:

On 13-07-22 7:40 AM, lchenneb...@gmail.com wrote:


When do you think it will be released?




Maybe in Firefox 26 or 27. I have a working patch, but am struggling to 
find time to finish it up.



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

Re: review stop-energy (was 24hour review)

[Chris Pearce]

On 7/11/2013 8:55 AM, Boris Zbarsky wrote:

On 7/11/13 11:37 AM, Robert O'Callahan wrote:

While I think your observations are useful, I think (hope!) you are a
massive outlier


Somewhat.  My list was based on not only what makes my reviews slow 
but what I've heard people mention as making reviews slow.


I do agree we shouldn't design a policy based on my review queue. ;)


Maybe you need to start farming out reviews to other/newer members of 
the teams you work on? We've done that in media; giving reviews to the 
newer members of the team has been a great way to spread the load, and 
upskill the other team members.


Obviously some patches need the attention of an experienced hacker like 
yourself, but style nitsand mechanical errors etc can be picked up a 
less experienced reviewer. You could always look for the big issues, 
feedback+/- and then reassign the review request to another reviewer.



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

Re: Code Review Session

[Chris Pearce]

On 5/23/2013 5:32 PM, Scott Johnson wrote:

Members of dev-platform:

As part of the Web Rendering work-week in Taiwan, we had a discussion of
the process of code review, graciously led by roc. If you were unable to
attend, or were able to attend and would like to review the proceedings,
notes are available here:
https://etherpad.mozilla.org/TaiwanWorkWeekCodeReview

Special thanks to Anne van Kesteren and Daniel Holbert for assisting me
in the note-taking when my laptop battery died.

~Scott


Video of the session is available at:
http://people.mozilla.org/~cpearce/CodeReviews-Taipei-May2013.mp4
(1 hour 10mins duration, 346MB)

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

Re: Platform meeting changes effective June 2013

[Chris Pearce]

On 5/31/2013 3:25 AM, Lawrence Mandel wrote:

2. Work on summarizing discussions or vague items in the agenda so that the 
notes can be understood by people who don't attend the meeting

Please let me know how the notes shape up.


As someone who can't attend most meetings due to inconvenient time 
zones, I greatly appreciate good meeting notes, and I regularly try to 
read them. Thanks for taking charge of this!



Cheers,
Chris Pearce.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Kyle Huey's Cycle Collector talk from Taipei meetup

[Chris Pearce]

On 6/14/2013 10:02 AM, Chris Pearce wrote:
At the recent Web Rendering team meetup in Taipei Kyle gave a talk 
about how Gecko's cycle collector works, including covering what 
macros you need to use to ensure the cycle collector knows about your 
objects.


We borrowed a camera from one of the Taipei team and recorded the 
talk, here it is for your viewing pleasure:


http://people.mozilla.com/~cpearce/cycle-collector-khuey-Taipei-23May2013.mp4 





There's a WebM transcode available for download here:
http://people.mozilla.org/~cpearce/khuey-cycle_collector-Taipei-May2013.webm

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

Kyle Huey's Cycle Collector talk from Taipei meetup

[Chris Pearce]

At the recent Web Rendering team meetup in Taipei Kyle gave a talk about 
how Gecko's cycle collector works, including covering what macros you 
need to use to ensure the cycle collector knows about your objects.


We borrowed a camera from one of the Taipei team and recorded the talk, 
here it is for your viewing pleasure:


http://people.mozilla.com/~cpearce/cycle-collector-khuey-Taipei-23May2013.mp4


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