Re: Adopting the black Python code style

Hi, Unfortunately I don't think consensus is possible with code formatting. Partly for that reason, we (Fx engineering leadership and others) have concluded that automatic, standardized code formatting is the right thing to do. We've already done this for a few languages and Python is up next.

Re: [ Intent to Change ] Enabling the Triage Lead role to see security bugs in their component

 Thank you! On Wed, Aug 28, 2019 at 1:51 PM Emma Humphries wrote: > When work on https://bugzilla.mozilla.org/show_bug.cgi?id=1417229 is > completed and the patch deployed to Bugzilla, users who are a Triage Owner > will be able to see security bugs in their components without needing >

Re: Intent to unship AppCache

It's been a long time coming :) Do you know if Chrome plans to drop support, too? On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston wrote: > The design of AppCache brings many problems to the web platform from a > performance and security perspective. Service workers have long solved the > same

Re: Crash-stop integrated by default for crash reports in Bugzilla

That looks like it could be incredibly useful! Thanks for pointing it out and for doing the work. On Thu, Jan 17, 2019 at 11:50 AM Calixte Denizet wrote: > Hi, > > A few months ago, we published the first version of the crash-stop addon > [1]. The goal was to integrate crash data along with

Re: Intent to ship: Unprefixed Fullscreen API

Congrats on getting this far, Xidorn! I know it's been years of work by you and others. On Mon, Sep 17, 2018 at 7:48 PM 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 >

Re: Intent to ship: Array.prototype.values

On Fri, Feb 2, 2018 at 8:45 AM, Tom Schuster wrote: > Chrome seems to > want to add a kill pref for this, from my experience more difficult > for us with the way we define methods in SpiderMonkey. Should that be > a requirement for shipping? > If it's not too difficult it

Re: Intent to enable scrollbars by default for windows opened by window.open()

We got a bug report that things are not working here: https://bugzilla.mozilla.org/show_bug.cgi?id=1429900. Ben, can you take a look? On Mon, May 23, 2016 at 2:25 AM, Ben Tian wrote: > Hi, > > I’m planning to enable scrollbars by default for windows opened by > window.open().

Re: Intent to implement (again): Shadow DOM

Custom Elements is being tracked separately. Watch for an intent email regarding them soon. On Tue, Nov 28, 2017 at 8:05 AM wrote: > Is this just shadow dom or there will be also support for custom elements? > > Thanks > ___ >

Re: Overriding JS to allow for opening in a new tab?

On Thu, Oct 26, 2017 at 12:34 AM, Boris Zbarsky wrote: > Either approach would break at least some legitimate sites. > Thanks for confirming this. In general, as Myk points out, the question of when web pages should be > able to respond to what sorts of input, and whether

Overriding JS to allow for opening in a new tab?

Is there precedent for doing what a user intended which would be contrary to what the site is attempting? In the case that prompted my question, the user was attempting to middle-click open photos from a Facebook photo album in tabs but the middle-click was handled by the page's JS:

Re: Adding Examples to Intent to Implement/Ship Messages

Not a bad idea! You can feel free to add it to the wiki page under suggested additions. And remember, they're just guidelines :) On Sat, Oct 21, 2017 at 4:25 AM Philipp Kewisch wrote: > Hey Folks, > > One thing I've often been thinking when reading the Intent to >

Re: Device Memory header and JS API

On Wed, Sep 6, 2017 at 2:53 PM, Daniel Veditz wrote: > I do not know what are plans are about Client Hints in general, whether we > intend to or when, and obviously that's a prerequisite. > Client Hints is https://bugzilla.mozilla.org/show_bug.cgi?id=935216, FWIW.

Re: Response.body streams landing on trunk, default off

On Thu, Aug 10, 2017 at 11:29 PM, Ben Kelly wrote: > Many thanks to Till and Andrea for their hard work on streams! > And to you, too, Ben! And to Boris and others for their reviews. Congratulations, all, this has been some great teamwork and it's great to see it get this

Re: Extensions and Gecko specific APIs

On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: > Should we moz-prefix moz-specific extensions? We have been trying not to do that for Web-exposed APIs but maybe the extensions case is different? https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guiding_Principles

Re: Ambient Light Sensor API

Did we make a decision here? If not, what are we missing to make one? On Fri, Apr 28, 2017 at 1:55 PM, Anne van Kesteren wrote: > On Fri, Apr 28, 2017 at 7:10 PM, Eric Rescorla wrote: > > Rather, the policy is > > that we will move to requiring all new features

Re: Ambient Light Sensor API

On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: > Going back to Jonathan's (I think) question. Does anyone use this at all in > the field? > Chrome's usage metrics say <= 0.0001% of page loads:

Re: Intent to ship: Storage API estimate method

On Thu, Sep 22, 2016 at 2:03 AM, smaug wrote: > > On 09/21/2016 04:42 AM, Shawn Huang wrote: > >> >> ​Because ​Storage API needs to have SecureContext support, but currently >> not having isSecureContext available in Workers (bug 1269052) is >> problematic. Can we initially

Are we in favour of implementing the client hints header?

Implement Client-Hints HTTP header https://bugzilla.mozilla.org/show_bug.cgi?id=935216 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: Web Storage (Second Edition)

On Thu, Jan 7, 2016 at 4:27 AM, Anne van Kesteren wrote: > On Thu, Jan 7, 2016 at 10:24 AM, L. David Baron wrote: > > Could you give a brief explanation of what the storage mutex is, and > > why it was/should be removed? > > It prevents races for storage and

Re: Collecting web platform features implementation status

Harald (on CC) is working on it here: https://github.com/mozilla/platatus On Oct 29, 2015 6:38 PM, "Tom Schuster" wrote: > Seems like this kind of died. I still would like to see this happening. Is > this on somebody's agenda? > > On Tue, Jul 21, 2015 at 8:40 PM, Tom Schuster

Tracking bugs for preffing on Service Worker (1059784 for initial pref-on)

We're using this meta-bug to track shipping Service Workers to the release channel on desktop and Android: https://bugzilla.mozilla.org/show_bug.cgi?id=1059784 For B2G-specific Service Worker issues we're using this meta-bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1131322 And for post-v1

Re: Intent to implement: BroadcastChannel API

On 01/10/14 04:46 AM, Mounir Lamouri wrote: On Wed, 1 Oct 2014, at 10:51, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 3:54 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Thu, 25 Sep 2014, at 02:49, Jonas Sicking wrote: Yes! Though as previously expressed, I don't think we should ship this

Tips for standardizing web APIs

A few of us have written some tips and suggestions to make standardizing web APIs easier. They're mostly intended for Mozillians and are most useful for those doing this for the first time. If you have suggestions, please let me know. https://wiki.mozilla.org/WebAPI/DesignGuidelines

30 minute weekly offline sync-ups Wednesdays at 8 AM Pacific

Tomorrow (Wed June 11th) we're starting short weekly sync-ups on our Service Worker efforts with a primary focus on offline functionality for the web. *Where*: WebAPI Vidyo room *When*: see this URL for the time in your timezone:

Strengthening special cases language in API exposure guidelines

Hi, I've been told that it would be nice if we had stronger language in our API exposure guidelines [1] around when we deviate from them. This is mostly applicable when we expose things to Firefox OS applications. The changes I propose to the Special cases section [2] are: -There will of

Re: Mozilla development bootcamp

, Andrew Overholt wrote: I'm planning to coordinate development material for new contributors and I'd like your input on what should be included: https://etherpad.mozilla.org/mozbootcamp Thanks! ___ dev-platform mailing list dev-platform

Re: Suggested API exposure guidelines redux

After some more suggested revisions (thanks again), I made these guidelines official as of October 22, 2013. Even though they aren't rules that are set in stone or anything like that, please consider these guidelines when exposing things to web content:

Mozilla development bootcamp

I'm planning to coordinate development material for new contributors and I'd like your input on what should be included: https://etherpad.mozilla.org/mozbootcamp Thanks! ___ dev-platform mailing list dev-platform@lists.mozilla.org

Suggested API exposure guidelines redux

Hi, When we expose new things to web developers, I'd like us to consider some suggestions. Due to a number of factors, I've made them suggestions and not a set of pan-module hard rules. https://wiki.mozilla.org/User:Overholt/APIExposurePolicy I've incorporated lots of feedback given on

WebAPI Meeting: Tuesday 20 August @ *8* AM Pacific [1]

Last notice: we've moved the meeting 2 hours earlier! 8 AM in California 11 AM in Toronto and New York, etc. 16:00 in the UK and Portugal 17:00 in most parts of Europe 23:00 in Taipei http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130820T08p1=224am=30

WebAPI Meeting: Tuesday 13 August @ *8* AM Pacific [1]

We've moved the meeting 2 hours earlier! 8 AM in California 11 AM in Toronto and New York, etc. 16:00 in the UK and Portugal 17:00 in most parts of Europe 23:00 in Taipei http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130813T08p1=224am=30 Meeting

WebAPI Meeting: **NEW TIME** Tuesday 6 August @ *8* AM Pacific [1]

We've moved the meeting 2 hours earlier! 8 AM in California 11 AM in Toronto and New York, etc. 16:00 in the UK and Portugal 17:00 in most parts of Europe 23:00 in Taipei http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130806T08p1=224am=30 Meeting

WebAPI Meeting: **NEW TIME** Tuesday 30 July @ *8* AM Pacific [1]

We're moving the meeting 2 hours earlier! 8 AM in California 11 AM in Toronto and New York, etc. 16:00 in the UK and Portugal 17:00 in most parts of Europe 23:00 in Taipei http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130730T08p1=224am=30 Meeting

WebAPI Meeting: Tuesday 23 July @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://etherpad.mozilla.org/webapi-meetingnotes * WebAPI Vidyo room * A room we can find, San Francisco office * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone

WebAPI Meeting: Tuesday 16 July @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://etherpad.mozilla.org/webapi-meetingnotes * WebAPI Vidyo room * A room we can find, San Francisco office * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone

No WebAPI Meeting July 9th

Due to most regular attendees being at a work week this week, we'll skip our call and restart it next week (July 16th). Send email or hop on #webapi for any issues. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Making proposal for API exposure official

Thank you to everyone that provided feedback. I've read everyone's comments and taken them into account with my new draft: https://wiki.mozilla.org/User:Overholt/APIExposurePolicy In general I tried to make it more of a set of requests and guidelines than a set of musts. I also clarified

WebAPI Meeting: Tuesday 2 July @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://etherpad.mozilla.org/webapi-meetingnotes * WebAPI Vidyo room * A room we can find, San Francisco office * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone

Re: Making proposal for API exposure official

On 24/06/13 01:50 PM, Kyle Huey wrote: 1. at least one other browser vendor ships -- or publicly states their intention to ship -- a compatible implementation of this API Because Apple and Microsoft generally do not publicly comment on upcoming features, and Presto is no more, in practice this

Re: Making proposal for API exposure official

On 24/06/13 05:52 PM, Ehsan Akhgari wrote: There are two things that I think can use clarification. One is what we're going to do about trivial changes? Do all web facing features ned to go through this process? I was going to put a blurb about trivial changes but thought it would be too

Re: Making proposal for API exposure official

On 25/06/13 12:15 PM, Mounir Lamouri wrote: Note that at this time, we are specifically focusing on new JS APIs and not on CSS, WebGL, WebRTC, or other existing features/properties. I think the JS APIs here is unclear. I think saying Web APIs would be more appropriate, assuming this is what

Re: Making proposal for API exposure official

On 26/06/13 11:48 AM, Ehsan Akhgari wrote: On 2013-06-26 11:21 AM, Andrew Overholt wrote: On 24/06/13 05:52 PM, Ehsan Akhgari wrote: There are two things that I think can use clarification. One is what we're going to do about trivial changes? Do all web facing features ned to go through

WebAPI Meeting: Tuesday 25 June @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://etherpad.mozilla.org/webapi-meetingnotes * WebAPI Vidyo room * A room we can find, San Francisco office * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone

Re: Making proposal for API exposure official

On 21/06/13 06:05 PM, Benoit Jacob wrote: Just to say, WebGL won't have to be an exception after all --- at least not newer WebGL extensions. Ah, thanks for letting me know. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Making proposal for API exposure official

On 21/06/13 05:56 PM, Adam Roach wrote: On 6/21/13 15:45, Andrew Overholt wrote: I'd appreciate your review feedback. Thanks. I'm having a hard time rectifying these two passages, which seem to be in direct contradiction: 1. Note that at this time, we are specifically focusing on /new/ JS

WebAPI Meeting: Tuesday 18 June @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://etherpad.mozilla.org/webapi-meetingnotes * WebAPI Vidyo room * A room we can find, San Francisco office * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone

WebAPI Meeting: Tuesday 4 June @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://etherpad.mozilla.org/webapi-meetingnotes * WebAPI Vidyo room * A room we can find, San Francisco office * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone

WebAPI Meeting: Tuesday 28 May @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://wiki.mozilla.org/WebAPI/2013-05-28 * WebAPI Vidyo room * A room we can find, San Francisco office * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone #

WebAPI Meeting: Tuesday 30 April @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://wiki.mozilla.org/WebAPI/2013-04-30 * WebAPI Vidyo room * Amoeba conf. room, San Francisco office (7A) * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone #

WebAPI Meeting: Tuesday 23 April @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://wiki.mozilla.org/WebAPI/2013-04-23 * WebAPI Vidyo room * Amoeba conf. room, San Francisco office (7A) * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone #

WebAPI Meeting: Tuesday 9 April @ 10 AM Pacific [1]

Meeting Details: * Agenda: https://wiki.mozilla.org/WebAPI/2013-04-09 * WebAPI Vidyo room * Amoeba conf. room, San Francisco office (7A) * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone #

WebAPI team plans

Yesterday a number of people discussed future plans for the WebAPI team. Our discussion resulted in the ideas and comments that are on this wiki page: https://wiki.mozilla.org/WebAPI/PlannedWork We'll add items to that page as time goes by and we'll pop items off it as we work on them.