Re: Adopting the black Python code style

[Andrew Overholt]

 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.

Ricky et al are the designated experts here and they recommend the plan
outlined up thread. They ran it by myself, Selena, EKR, and a few others in
management and we asked them to proceed.

If there are major showstoppers or something that wasn't taken into
account, please do let them know now. Otherwise I'd ask us all to try our
best to accept some of these things in the name of efficiency since we
won't all agree on everything :) Thankfully we can likely automatically
revert or re-format if we find issues -- once we get automatic formatting
working.

Thank you,

Andrew

On Tue, Oct 20, 2020 at 4:26 PM Jeff Gilbert  wrote:

> Well we generally don't seek consensus anymore for these sorts of
> things, it seems, but it's reassuring that I'm not alone.
>
> On Tue, Oct 20, 2020 at 1:17 AM James Graham 
> wrote:
> >
> > On 19/10/2020 22:01, Jeff Gilbert wrote:
> > > I'm disappointed by that.
> >
> > FWIW last time I looked at black, I found that the compromises it made
> > to be fully automatic and with minimal configuration meant that it was
> > liable to produce ugly or difficult to read code in some situations.
> >
> > I understand that we've decided that people will get used to reading any
> > code style over time, and therefore eliminating formatting concerns from
> > the code writing process is a net win for productivity. So I'm not
> > taking a position in opposition to this proposal, but it is not
> > something I would have advocated personally.
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

👏 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
> membership in security group or access through a role.
>
> This follows the same pattern as access for users in the reporter, qa
> contact, assignee, or cc list roles to security bugs.
>
> If the triage owner for a component changes, the new owner will have access
> and the previous owner, unless they have access through another means
> (role, or group membership,) will not.
>
> We expect this to go to production within the next two weeks.
>
> Many thanks to DKL for working on a patch for this.
>
> Emma Humphries, Bugmaster
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship AppCache

[Andrew Overholt]

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 use cases as AppCache.
>
> Removal of this code would bring a large reduction of code and complexity
> that is largely unmaintained.
>
> History
>
> Four years ago, in Firefox 44, we marked the API as deprecated[1].
>
> Back last year in Firefox 62, we disabled insecure AppCache and Chrome
> followed suit[2].
>
> Safari 11.1 added support for Service Workers, which are a replacement
> technology [3].
>
> Metrics
>
> Chrome measures a few different metrics here which suggest 2.3%[4] of
> secure page loads attempt to use the document visible API whilst only
> 0.27%[5] actually use the offline cache.
>
> Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
> however we don’t have a distinct metric for the API usage.
>
> The last blocker for a removal was usage of AppCache by some Microsoft
> online products.  I’m enquiring into if this is still applicable and also
> want to ensure with this rollout plan that we don’t break these when the
> user has an online connection.
>
> Implementation
>
> Bug where the code will be implemented[7].
>
> Plan
>
>-
>
>In Firefox 70, Remove the previous preference
>“browser.cache.offline.insecure.enable” and related code, forcing all of
>the APIs to only ever be available over Secure Contexts despite user
>choice. Due to the insecure nature of insecure context AppCache it is a
>good time now to remove this fully.
>
>
>-
>
>Create a new preference that disables only the storage and use of
>AppCache data whilst permitting access to the dom property
>window.applicationCache and the “OfflineResourceList” interface.
>-
>
>   Disable access in Nighty and beta for 70 for two releases before
>   disabling for all other releases in 72.
>   -
>
>   Once storage is disabled in all releases:
>   -
>
>  Disable the API access in Nightly and beta via the existing
>  preference (browser.cache.offline.enable) in version 72.
>  -
>
>  Wait two releases and then disable in all releases in Firefox 74.
>
>
> This staged removal of AppCache is to reduce the risk of web compatibility
> issues of the API being accessible to page scripts. Despite the API
> presence it won’t have any ability to use the cache. We may look into
> shimming these APIs depending on how the rollout plan goes.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1204581
>
> [2]
>
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/qLTTpdzcDkw/WKJeq-4HAQAJ
>
> [3]
>
> https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html
>
>
> [4] https://www.chromestatus.com/metrics/feature/timeline/popularity/1248
>
> [5] https://www.chromestatus.com/metrics/feature/timeline/popularity/1246
>
> [6] https://mzl.la/2TKRbvA
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1237782
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Custom Search UI now available on Bugzilla

[Andrew Overholt]

The recent improvements to Bugzilla are greatly appreciated! Congrats and
thank you to you and the team on the steady stream of awesomeness.

On Thu, Jun 27, 2019 at 8:18 PM Kohei Yoshino  wrote:

> Hi there,
>
> We have enhanced search features on Bugzilla over the past months, because
> we know people search a lot. I want to let you know some of our goodies
> recently added to make your life easier.
>
>- New Custom Search UI on the Advanced Search page
>: It was
>previously hard to build complex queries because of the poorly designed UI.
>Today we have shipped a completely new UI that allows you to add
>rows/groups, move them with a drag-and-drop, and remove ones if necessary.
>
>
>- Aliases for status & tracking flags: Each Firefox release has status
>and tracking flags like “status-firefox67” or “tracking-firefox68” but
>sometimes you may just want to find bugs by a specific channel. You can now
>use convenient aliases like “status-firefox-release” or
>“tracking-firefox-beta” so you don’t have to update your search queries
>every 7 weeks or so.
>
>
>- Merge date pronouns: You can now use Firefox merge date pronouns,
>including “%LAST_MERGE_DATE%” and “%LAST_RELEASE_DATE%”, for date fields.
>
>
>- Search in bug description: Searching in comments can be slow, but if
>you know what you’re looking for is in the bug’s description (comment 0),
>you can get results faster by ticking the “Description (initial comment)
>only” checkbox on the Advanced Search page.
>
> So what’s next? We are currently working on an overhaul of the search
> results page , that
> will be richer and faster than the current plain table presentation. It
> should be coming in the next month or two.
>
> Happy searching!
>
> Kohei, for the Bugzilla team
>
> ___
> release-drivers mailing list
> release-driv...@mozilla.org
> https://mail.mozilla.org/listinfo/release-drivers
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

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 some analysis (ex:
> startup crashes) directly into Bugzilla. The goal is to help with bug
> prioritization and make it easier to determine if a patch has fixed the
> issue after it lands.
>
> Following the example of the Bugzilla Socorro Lens, we have decided to
> enable this functionality for everyone directly in Bugzilla given its
> impact and usefulness. Thanks to Kohei’s work, the table containing the
> data is now displayed in crash bugs directly without the help of the addon.
> As an example, see the bug below:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1519468
>
> Users who have previously installed the crash-stop addon can safely remove
> it now.
>
> For more information on the displayed data:
>
> https://crash-stop-addon.herokuapp.com/
>
> If you see something wrong or if you want to have more data, please feel
> free to file a bug:
>
> https://github.com/mozilla/crash-stop-addon
>
> Calixte
>
> [1] https://addons.mozilla.org/firefox/addon/bugzilla-crash-stop/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Unprefixed Fullscreen API

[Andrew Overholt]

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

Re: Intent to ship: Array.prototype.values

[Andrew Overholt]

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 does make it a lot easier to fix things if it
causes major breakage. I think we can even do a pref flip without shipping
an update which is pretty nice.

Is there a way to do per-site pref changes? Did we do this for Stylo,
Emilio?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

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().
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1257887
>
> This change intends to enable scrollbars by default when “scrollbars”
> doesn't appear in the feature argument of window.open(), and to disable
> only when opener pages specify explicitly. Currently window.open() disables
> scrollbars by default unless the feature argument enables explicitly or is
> an empty string. However in the majority of the cases the user will want to
> be able to scroll, and a lot of accessibility docs recommend enabling
> scrollbars by default.
>
> Chrome and Safari don't provide a way to disable scrollbar, according to
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1257887#c0
>
> If you have any concern or know of regression on pages relying on current
> behavior, please let me know.
>
>
> -Ben
>
> --
> Ben Tian,
> Engineering Manager
> System Engineering Lead
> Mozilla Corporation
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement (again): Shadow DOM

[Andrew Overholt]

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

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

[Andrew Overholt]

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 they should be able to
> prevent the default browser respond to that same input, is something that
> keeps coming up.  It's not clear to me that there is a general
> context-independent answer here.


Ok, thanks for the clarification (also to Myk and Dave!). Sounds like in
this case there's no easy answer.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Overriding JS to allow for opening in a new tab?

[Andrew Overholt]

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:
https://bugzilla.mozilla.org/show_bug.cgi?id=1365260. Maybe this is just a
middle-click thing?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Adding Examples to Intent to Implement/Ship Messages

[Andrew Overholt]

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
> Ship/Implement emails is "Hey, that sounds interesting, I wonder what
> that is and how I can use it".
>
> The spec and bug is usually linked, so I can go ahead and take a look at
> the spec, but what would make reading email a lot easier for me is a
> short summary of what the spec does and an example how it can be used.
>
> For example, the pointer events spec recently had an Intent to Ship. As
> I haven't read about it earlier, all I know is that the name suggests it
> has something to do with the mouse, but until I skim the first few
> screens of the spec until Example 1, I am not sure what it does. The
> following info would have been helpful:
>
> """
> Pointer Events are like mouse events, but more general. It provides
> similar information for devices like touchscreens, pen input, etc. Here
> is a simple example:
>
> window.addEventListener("pointerdown", function(event) {
>   console.log(event.pointerType); // "pen", "mouse", etc.
>   console.log(event.width); // width of contact geometry
> });
>
> """
>
> Do others think this information would be helpful, and if so, can we get
> this added to the process for Intent to Ship and Intent to Implement?
>
> Philipp
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Andrew Overholt]

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

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

[Andrew Overholt]

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

Re: Extensions and Gecko specific APIs

[Andrew Overholt]

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

Re: Ambient Light Sensor API

[Andrew Overholt]

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 to have HTTPS [0].
>
> We should probably discuss that again at some point, since it's not
> meaningfully enforced and I don't think it has consensus within
> Mozilla either. It's also very much unclear what the scope of it is,
> whether a new CSS property should get that treatment, a new method on
> Node, etc.
>
>
> > [0]
> > https://blog.mozilla.org/security/2015/04/30/
> deprecating-non-secure-http/
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Andrew Overholt]

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:
https://www.chromestatus.com/metrics/feature/popularity#AmbientLightSensorConstructor.
We are going to collect telemetry in
https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Storage API estimate method

[Andrew Overholt]

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 release the Storage API without Worker
>> support?
>>
>
> That sounds a tad worrisome. Is there a reason why we can't wait until we
> have SecureContext also in workers?
>

I encouraged Shawn to send this to gauge people's thoughts on whether we
could ship without Worker support. It seems you're on the side of waiting
until we have SecureContext support in Workers :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Are we in favour of implementing the client hints header?

[Andrew Overholt]

 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)

[Andrew Overholt]

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 cookies when your tabs run in
> independent processes. It was removed because nobody cared for
> implementing it.


Is that related to https://bugzilla.mozilla.org/show_bug.cgi?id=666724 ?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Collecting web platform features implementation status

[Andrew Overholt]

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  wrote:
>
> > I see 3 (now 4) old pull requests that are unmerged.
> >
> > On Tue, Jul 21, 2015 at 8:19 PM, Anthony Ricaud 
> wrote:
> >
> >> On 16/07/15 21:26, Anthony Ricaud wrote:
> >>
> >>> Potch and I are working on a website to present Mozilla's point of view
> >>> on various web platform features. Other browsers have similar websites
> >>> [1] [2] [3]. This project has been in lingo for a while so, to get it
> >>> out the door, we're going to focus on one information: what is
> Mozilla's
> >>> opinion on features that have not been shipped yet. We see 4 possible
> >>> answers: in development, favorable, not favorable, no opinion.
> >>>
> >>> In order to get accurate data and update it regularly, we need your
> >>> help. Please go to the following etherpad and insert any information
> >>> that can help us:
> >>> https://etherpad.mozilla.org/gecko-web-platform-dashboard
> >>>
> >>> Thanks for your help!
> >>>
> >>> [1] https://www.chromestatus.com/features
> >>> [2] https://status.modern.ie
> >>> [3] http://www.webkit.org/status.html
> >>>
> >> Reminder: We need your help! Please submit a pull request against
> >> https://github.com/Rik/platform-status/blob/master/features.json.
> >>
> >> (I've only received one pull request since moving this JSON to Github
> :( )
> >>
> >> ___
> >> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

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" bugs we're using this meta-bug:

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

When you're testing and filing bugs (of course you are), feel free to hang
them off the "v3" meta-bug (1173500) or just file them in
Core::DOM::Service Workers. Testing network interception in non-e10s mode
is especially appreciated (because SW will hopefully ship first on a
non-e10s release)!

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

Re: Intent to implement: BroadcastChannel API

[Andrew Overholt]

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 
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 until
it
supports sending Blobs.


What do other UAs implement?


I don't know. Does anyone else implement BroadcastChannel yet?


It seems an information that would be worth adding to Intent to
{Implement,Ship}.


Good idea.  Done: 
https://wiki.mozilla.org/index.php?title=WebAPI%2FExposureGuidelines&diff=1020648&oldid=1003407 
.


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

Tips for standardizing web APIs

[Andrew Overholt]

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

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

[Andrew Overholt]

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:
http://arewemeetingyet.com/Toronto/2014-06-11/11:00/w/Offline%20sync-up

All of you lovely readers are welcome to join to hear how we're doing 
but I won't be sending reminder emails.  If you want me to send you a 
recurring calendar invite, email me.

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

Strengthening "special cases" language in API exposure guidelines

[Andrew Overholt]

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 course be special cases where we deviate from this
+There may be special cases where we deviate from this
 goal.  New user-facing products like Firefox OS may need to ship
 APIs that have not yet been embraced by other browser engines or
 thoroughly discussed by standards bodies.  This allows Mozilla to
 provide functionality that other browser engines aren't working
 on or the majority of the Web community isn't interested in at
 that time.  Examples of such functionality include telephony and
 Bluetooth.  This functionality is most often only exposed to
 Firefox OS applications of elevated privileges and not via the
 Firefox OS browser application.
+It is '''highly unlikely''' that we will expose this functionality
+to the web at large.


If you agree with the intent but have wording suggestions, please send 
them to me and let's avoid bikeshedding on the list.


If no one expressed disagreement here by Friday 25 April 2014, I'll make 
the changes on the wiki.


Thanks,

Andrew

[1]
https://wiki.mozilla.org/WebAPI/ExposureGuidelines

[2]
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Special_Cases
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mozilla development "bootcamp"

[Andrew Overholt]

I'm thinking all new contributors (volunteer or paid) and presented 
online as a series of videos (where applicable) with accompanying 
documentation.


On Wed 30 Oct 2013 04:14:17 PM EDT, Josh Matthews wrote:

Who is the audience? Where will this information be presented?

On 10/30/2013 02:58 PM, 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@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

Mozilla development "bootcamp"

[Andrew Overholt]

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

Re: Suggested API exposure guidelines redux

[Andrew Overholt]

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:


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

Suggested API exposure guidelines redux

[Andrew Overholt]

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 previous revisions (thanks!) 
and feel like this is ready to go.


Let me know if you want me to hold off on presenting these at an 
upcoming Tuesday engineering meeting and moving them out of User:Overholt.


Thanks,

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

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

[Andrew Overholt]

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+meeting&iso=20130820T08&p1=224&am=30

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130820T08&p1=224&am=30
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

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+meeting&iso=20130813T08&p1=224&am=30

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130813T08&p1=224&am=30
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

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+meeting&iso=20130806T08&p1=224&am=30

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130806T08&p1=224&am=30
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

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+meeting&iso=20130730T08&p1=224&am=30

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130730T08&p1=224&am=30
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130723T10&p1=224&am=30 



Please comment on potential new meeting time:


https://groups.google.com/d/msg/mozilla.dev.webapi/ySb3gLSCYS8/1frJTXelNhUJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130716T10&p1=224&am=30 


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

No WebAPI Meeting July 9th

[Andrew Overholt]

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

Re: Making proposal for API exposure official

[Andrew Overholt]

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 "must"s.  I also clarified some of the wording around what 
it means for something to be "standardized" or "ready for shipping".


It's ready for another round of feedback when people have time.

Thanks again!

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

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130702T10&p1=224&am=30 


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

Re: Making proposal for API exposure official

[Andrew Overholt]

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 this process?


I was going to put a blurb about "trivial changes" but thought it would
be too hard to define.


Sorry, I was wrong here.  I didn't put it in because I intended the 
policy to only cover new APIs.  I guess we could say "new APIs or major 
changes to existing APIs" ...


Andrew

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

Re: Making proposal for API exposure official

[Andrew Overholt]

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 you meant.


I waffled on this but if you think "[Ww]eb APIs" is more clear, I'll go 
with that.



Also, I do not understand why we are excluding CSS, WebGL and WebRTC. We
should definitely not make this policy retro-apply so existing features
should not be affected but if someone wants to add a new CSS property,
it is not clear why this shouldn't go trough this process.


My hope was to get something in place for APIs and then build up to 
other web-exposed "things" like CSS, etc.



1. Is the API standardized or on its way to being so?
2. Declaration of intent
3. API review
4. Implementation
5. Shipping


I think 2) should be "Declaration of intent to implement" and we should
add an item between 4) and 5) named "Declaration of intent to ship".
Those two distinct items are important I believe.


Done.  Although note that others have expressed concern about the 
"intent to ship"->"shipping" situation.



2. at least two other browser vendors ship a compatible
implementation of this API


I will join Henri: "browser vendors" should be "browser engines" and


Fixed.


"ship" is too restrictive. If a feature is implemented and available in
some version (even behind a flag) with a clear intent to ship it at some
point, this should be enough for us to follow.


I changed it to "at least two other browser engines ship (regardless if 
it's behind a flag or not in their equivalent of beta or release) -- a 
compatible implementation of this API ".  How's that?  I don't want to 
see us basing our decision to ship on another engine's use of their 
nightly equivalent for experimentation (whether this happens right now 
or not).  Am I worried for no reason?



3.  at least one other browser vendor ships -- or publicly states
their intention to ship -- a compatible implementation of this API
and there is a specification that is no longer at risk of significant
changes, on track to become a standard with an relevant standards
body, and acceptable to a number of applicable parties


Actually, with this point, point 2) sounds barely useful. The only
situation when we could have 3) applying but not 2) would be if two
engines implement a feature that has no specification.


That was the situation I was thinking of :)


2. ecosystem- and hardware-specific APIs that are not standard or of
interest to the broader web at that time (or ever) may be shipped in
a  way to limit their harm of the broader web (ex. only on a device
or only in specific builds with clear disclaimers about applicability
of exposed APIs). An example of this is the FM Radio API for Firefox
OS.


When I read this, I read "It is okay to have Mozilla ship a phone with
proprietary APIs". That means that we are okay with Mozilla creating the
situation Apple created on Mobile, a situation that Mozilla has been
criticising a lot. Shipping proprietary APIs on a specific device is
harming the broader Web if that device happens to be one of the most
used device out there...


The way you read it obviously not something we want to do.  What if we 
dropped the "ecosystem-"?  I can't see how we can allow ourselves to 
ship hardware-specific APIs that don't work everywhere without an 
exception like this.  Are there situations where we would ship such an 
API on desktop if there's very little chance of the required hardware 
existing there?



3. APIs solving use cases which no browser vendor shipping an engine
other Gecko is interested in at that time. In cases such as this,
Mozilla will solicit feedback from as many relevant parties as
possible, begin the standardization process with a relevant standards
body, and create a test suite as part of the standards process. An
example of this is the Push Notifications API.


I am not a big fan of that exception.


That was my attempt to not limit our ability to innovate without other 
engines.  I'm open to alternative phrasings.



Declaring Intent
API review
Implementation
Shipping


I think some clarifications are needed in those areas.


I changed the section headers to:

Declaring Intent to Implement
API review
Implementation
Intent to Ship and Shipping

How's that?


Intent emails
should be reviewed by "dev-platform", not a "API review team". In other
words, any one should be able to express its opinion and opinions will
be listened based on their technical value, not based on affiliation.


I added some wording to clarify that the email should do _both_.  I was 
also not assuming affiliation would necessarily define the "API review 
team".



The issue with having "dev-platform" finding a consensus with intent
emails is that we might end up in a infinite debate. In that case, we
should use the module system and have the mo

Re: Making proposal for API exposure official

[Andrew Overholt]

On 25/06/13 10:11 AM, Brian Smith wrote:

In the document, instead of creating a blacklist of web technologies to which 
the new policy would not apply (CSS, WebGL, WebRTC, etc.), please list the 
modules to which the policy would apply.


I started building up a list of modules to which the policy would apply 
but it grew quickly and there are a lot of modules in Core.  How do you 
feel about refining the definition of "web-exposed feature" and then 
saying it applies to all modules but the module owner has veto power for 
applicability?


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

Re: Making proposal for API exposure official

[Andrew Overholt]

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 hard to define.  Would you be okay with it being in there with 
something like "definition of triviality is left up to the module owner"?



The other question is, what we're going to do about negative feedback
from the API review phase but where the feedback cannot be incorporated
because of other concerns?


I was thinking the module owner (or I guess the DOM module owner in 
certain cases) would make the call.  But maybe I'm misunderstanding what 
sort of feedback you're thinking of; can you give an example?


Thanks,

Andrew

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

Re: Making proposal for API exposure official

[Andrew Overholt]

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 will boil
down to a minimum condition of the Blink developers stating their
intention to ship an API (in Chrome, presumably).  That feels too
restrictive to me.  Blink's policy talks about "positive signals" from
other vendors which is much more vague.  I worry that the proposed
language is too rigid and will either restrict us from innovating or
worse, be ignored.


What if we clarified earlier in the policy that things hidden behind 
flags are exempt from these requirements, like Ehsan pointed out Blink does?



4. "Disputes between the API review team and the API developers will be
decided by the module owner for the API's area."

I'm not sure that there is even a module owner here to decide things.


How do you feel about Ehsan's suggestion of using the DOM module owner 
as an arbiter?



5. "Once one week has passed [...]

This seems unnecessarily heavy-handed to me.


Agreed so I'll remove it.  I'm actually thinking we still have the email 
request but only to inform those who are interested in the feature 
landing but haven't been following the bug closely.  What do you think? 
 What about you, Ehsan?


Thanks for the feedback!

Andrew

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

Re: Making proposal for API exposure official

[Andrew Overholt]

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
APIs and not on CSS, WebGL, WebRTC, or other existing
features/properties"

 2. "This policy is new and we have work to do to clean up previous
divergences from it."


I expect that the first statement is the correct one, given that the
goal here is to prevent wholesale breaking of deployed sites. It also
aligns with what I've heard from parties who have been involved in the
conversations to date.


Yes, "Don't break the web" is an overarching goal but what I'm proposing 
deals specifically with new-to-the-web APIs.


The second statement you note above is me trying to indicate that we 
know we haven't been perfect at this in the past and need to go back and 
fix a few things.  Do you think I should just say that explicitly?


Thanks for the feedback,

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

Re: Making proposal for API exposure official

[Andrew Overholt]

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

Re: Making proposal for API exposure official

[Andrew Overholt]

On Fri 21 Jun 2013 06:44:08 PM EDT, Robert O'Callahan wrote:

I think "APIs which only Mozilla is interested in at that time" needs
clarification that this refers to APIs that solve use cases that only
Mozilla is interested in. If other vendors are interested in those
use-cases, but don't like our API proposal, we can't just brush that off.


Thanks, I changed this to be:

 "APIs solving use cases which no browser vendor shipping an engine 
other Gecko is interested in at that time. In cases such as this, 
Mozilla will solicit feedback from as many relevant parties as 
possible, begin the standardization process with a relevant standards 
body, and create a test suite as part of the standards process. An 
example of this is the Push Notifications API."


Anne suggested the "no browser vendor shipping an engine other than 
Gecko" part.

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

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130625T10&p1=224&am=30 


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

Making proposal for API exposure official

[Andrew Overholt]

Back in November, Henri Sivonen started a thread here entitled 
"Proposal: Not shipping prefixed APIs on the release channel" [1].  The 
policy of not shipping moz-prefixed APIs in releases was accepted AFAICT.


I've incorporated that policy into a broader one regarding web API 
exposure.  I'd like to see us document this so everyone can easily find 
our stance in this area, similar to how they can with Blink [2].


I've put a draft here:

  https://wiki.mozilla.org/User:Overholt/APIExposurePolicy

I'd appreciate your review feedback.  Thanks.

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/34JfwyEh5e4/emA1LAoVEVQJ

[2]
http://www.chromium.org/blink#new-features
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130618T10&p1=224&am=30 


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

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130611T10&p1=224&am=30 


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

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130604T10&p1=224&am=30 


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

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130528T10&p1=224&am=30 


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

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

[Andrew Overholt]

Meeting Details:

* Agenda: https://wiki.mozilla.org/WebAPI/2013-05-07
* 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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome!

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130507T10&p1=224&am=30 


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

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome!

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130430T10&p1=224&am=30 


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

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome!

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130423T10&p1=224&am=30 


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

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

[Andrew Overholt]

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 # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome!

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130409T10&p1=224&am=30 


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

WebAPI team plans

[Andrew Overholt]

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.  As always, we're interested in your suggestions and 
input so please feel free to get in touch via dev-webapi, #webapi, or 
our weekly meetings on Tuesdays at 10 AM Pacific in the WebAPI Vidyo 
room [1].


Thanks,

Andrew

[1]
https://wiki.mozilla.org/WebAPI#Meetings
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform