Re: Intent to ship: Unprefixed Fullscreen API

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: >

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

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 yo

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

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 > &

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

ote: > > 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. > > > > I

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

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 > &

Intent to implement and ship: HTMLMediaElement.allowedToPlay

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

Re: Intent to ship: block audible autoplay media intervention

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 a

Re: Intent to ship: block audible autoplay media intervention

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 Frid

Re: Intent to ship: block audible autoplay media intervention

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 Mo

Re: Intent to ship: block audible autoplay media intervention

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: > > > >

Re: Intent to ship: block audible autoplay media intervention

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: > > DE

Intent to ship: block audible autoplay media intervention

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

Re: Follow up on clang-format

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

Re: Follow up on clang-format

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

Intent to remove: EME support on insecure contexts

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

Re: Phabricator Update, July 2017

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 >

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

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.

Re: Start logging at runtime (Firefox 52)

; > > 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 > &

Re: Start logging at runtime (Firefox 52)

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

Intent to remove: Insecure use of Encrypted Media Extensions

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

Re: Tier 3 win64 ASan builds on try

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

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

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:

Re: e10s-multi update and tests

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

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

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

Re: All the processes

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

Re: Removing navigator.buildID?

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

Re: Faster gecko builds with IceCC on Mac and Linux

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

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

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:* Thu

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

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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

Re: Generating Visual Studio project files by default

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:

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

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

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

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

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

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

Re: Replacing PR_LOG levels

. 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

Re: Replacing PR_LOG levels

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

Re: Replacing PR_LOG levels

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

Re: Mozillabuild 2.0 ready for testing

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

Re: Mozillabuild 2.0 ready for testing

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

Re: e10s is now enabled by default for Nightly!

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/

Re: e10s is now enabled by default for Nightly!

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

Re: fopen, gtest and try

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

Re: Intent to Implement: Encrypted Media Extensions

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

Intent to Implement: Encrypted Media Extensions

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

nsRefPtr vs RefPtr

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

Re: Visual Studio Project Generation

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

Re: CPP_UNIT_TESTS being removed from make check

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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. ___

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

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

Re: Code Review Session

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

Re: Platform meeting changes effective June 2013

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

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

Kyle Huey's Cycle Collector talk from Taipei meetup

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