Re: Web IDL interfaces now require explicit [Exposed] annotations

[Eric Shepherd (Sheppy)]

Is the page “WebIDL bindings” up to date as well? I often find it useful
too.

https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings

On October 1, 2019 at 5:58:36 AM, Christopher Mills (cmi...@mozilla.com)
wrote:

I've removed the mention of PrimaryGlobal from
https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file
.
It was only a small mention.

I also removed the separate mention of the default value:

"If no annotation is available, the default value is Window."


Eric Shepherd
Senior Technical Writer
MDN Web Docs <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Doc review request for MIME type “codecs” parameter article

[Eric Shepherd (Sheppy)]

If anyone has time to spare at some point, I've finished drafting a new
article "The 'codecs' parameter in common media types” [1]. It’s intricate
enough, and gathers enough information from a wide enough variety of tricky
sources, that it would really benefit from a review for technical accuracy
from people with a closer familiarity with the topic.

Make corrections, or suggest them to me and I’ll make them if you’re not
comfortable doing it yourself. I’m not picky. ;)

Thank you in advance!

[1]
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/codecs_parameter


Eric Shepherd
Senior Technical Writer
MDN Web Docs <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Eric Shepherd (Sheppy)]

I’m glad to hear it; the presence of the EV indicator often occupied so
much space that the URL bar would become practically unusable. Example
attached.


On August 12, 2019 at 4:05:09 AM, Johann Hofmann (jhofm...@mozilla.com)
wrote:

The Chrome team recently removed EV indicators from the URL bar in Canary
and announced their intent to ship this change in Chrome 77
<https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/h1bTcoTpfeI>.
Safari is also no longer showing the EV entity name instead of the domain
name in their URL bar, distinguishing EV only by the green color. Edge is
also no longer showing the EV entity name in their URL bar.


Eric Shepherd
Senior Technical Writer
MDN Web Docs <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement & Ship: WebRTC Perfect Negotiation APIs

[Eric Shepherd (Sheppy)]

Pleased to see these changes coming. It will improve the negotiation
process’s reliability while at the same time making it easier to explain to
new developers.

On July 23, 2019 at 9:15:06 PM, Jan-Ivar Bruaroey (j...@mozilla.com) wrote:

"Perfect Negotiation" refers to four API improvements to WebRTC that
together make signaling non-racy and more ergonomic. They are (with FF
target and bug #):

1. 70 http://bugzil.la/1551316 restartIce()
2. 70 http://bugzil.la/1567951 setRemoteDescription() with "rollback"
3. 70 http://bugzil.la/1568292 setLocalDescription() without arguments
4. 71 http://bugzil.la/1568296 Stopping and stopped transceivers


Eric Shepherd
Senior Technical Writer
MDN Web Docs <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Image format documentation review requested

[Eric Shepherd (Sheppy)]

I’ve just finished writing up a guide to image file types and formats.
Before making it widely hooked into the main body of our documentation, I
would like to get it reviewed by engineers to ensure accuracy.

https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types

Feel free to edit the article in place (log in to MDN and click the edit
button at the top of the page), or if you’re uncomfortable with that, just
email me your suggestions.

Things to look for:


   - Factual errors
   - Things that are important that aren’t mentioned
   - Things mentioned that should not be
   - Anything explained awkwardly
   - Anything else you think should be fixed, changed, or added

The goal isn’t to be a complete detailed list of every fact about every
format, but to provide enough information to allow a developer to decide
what makes sense for them to use.


Eric Shepherd
Senior Technical Writer
MDN Web Docs <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS 'prefers-color-scheme' media feature

[Eric Shepherd (Sheppy)]

Presumably that’s noted appropriately in some manner in Bugzilla?

On March 19, 2019 at 7:45:53 PM, Hiroyuki Ikezoe (hike...@mozilla.com)
wrote:

The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
just landed on mozilla-central, will be shipped in Firefox 68.


Eric Shepherd
Senior Technical Writer
MDN Web Docs <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: break-before, break-after, break-inside CSS properties

[Eric Shepherd (Sheppy)]

I just now saw this; as both a developer and as a writer on the MDN docs
team, I can tell you this will really be fantastic to have, and I can’t
wait! Not having control over breaks makes a lot of layout fail, especially
when trying to use multiple columns or grids to do layout.

On December 7, 2018 at 9:12:39 AM, Emilio Cobos Álvarez (emi...@crisal.io)
wrote:

Summary: Implement these properties to control breaks in the page, make
page-break-{before,after} legacy shorthands of those.


Eric Shepherd
Senior Technical Writer
MDN Web Docs <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

[Eric Shepherd (Sheppy)]

No… although you could turn sync off again after the initial sync is complete, 
I guess.


--
Eric Shepherd
Senior Technical Writer
MDN Web Docs
https://developer.mozilla.org/

On Oct 23, 2018, 10:20 AM -0400, bruno ais , wrote:
> Can sharing with firefox sync be done just one way?
>
> > On Tue, Oct 23, 2018 at 3:18 PM Eric Shepherd (Sheppy) 
> >  wrote:
> > > Michael,
> > >
> > > Should be able to just enable sync in each copy of Firefox and sync the 
> > > items you need across profiles that way. Is that good enough?
> > >
> > >
> > > --
> > > Eric Shepherd
> > > Senior Technical Writer
> > > MDN Web Docs
> > > https://developer.mozilla.org/
> > >
> > > On Oct 23, 2018, 10:08 AM -0400, Michael Verdi , 
> > > wrote:
> > > > Is there a way migrate data from one profile to another? We 
> > > > occasionally run user tests and ask people to install beta or nightly 
> > > > so that they can test a feature with their current data (bookmarks, 
> > > > history, preferences, etc). Will Firefox show up in the import wizard?
> > > > Thanks,
> > > > Michael
> > > > --
> > > > Michael Verdi • Firefox Search UX • Slack: verdi
> > > > ___
> > > > firefox-dev mailing list
> > > > firefox-...@mozilla.org
> > > > https://mail.mozilla.org/listinfo/firefox-dev
> > > ___
> > > firefox-dev mailing list
> > > firefox-...@mozilla.org
> > > https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

[Eric Shepherd (Sheppy)]

Michael,

Should be able to just enable sync in each copy of Firefox and sync the items 
you need across profiles that way. Is that good enough?


--
Eric Shepherd
Senior Technical Writer
MDN Web Docs
https://developer.mozilla.org/

On Oct 23, 2018, 10:08 AM -0400, Michael Verdi , wrote:
> Is there a way migrate data from one profile to another? We occasionally run 
> user tests and ask people to install beta or nightly so that they can test a 
> feature with their current data (bookmarks, history, preferences, etc). Will 
> Firefox show up in the import wizard?
> Thanks,
> Michael
> --
> Michael Verdi • Firefox Search UX • Slack: verdi
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: HTMLMarqueeElement

[Eric Shepherd (Sheppy)]

Happy to see this coming. I'm (honestly) sort of a fan of , in a
twisted sort of way. A fun reminder of the whimsy of the early days of the
web, and amusing to use in certain types of examples.

On Sun, Oct 14, 2018 at 8:30 PM Karl Dubost  wrote:

>
>
> Le 13 oct. 2018 à 02:56, Brian Grinstead  a écrit
> :
> > Summary: […] I intend to implement and ship HTMLMarqueeElement.
>
> Very cool. And a support on that, from a webcompat standpoint of view,
> because it seems a lot of Indian websites rely on it. The current
> implementation has "performance" issues compared to other browsers where
> the animation is a lot smoother.
>
> > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1425874
>
> See https://bugzilla.mozilla.org/show_bug.cgi?id=306344
>
>
> --
> Karl Dubost, mozilla  Webcompat
> http://www.la-grange.net/karl/moz
>
>
>
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: User Agent Strings in Firefox and their history

[Eric Shepherd (Sheppy)]

Cool, thanks! If nothing else, please make sure they're not duplicating
material and that they link to each other.

On Thu, Sep 20, 2018 at 12:37 PM Mike Taylor  wrote:

> Hi Eric,
>
> On 9/20/18 11:21 AM, Eric Shepherd (Sheppy) wrote:
> > We actually have a page on MDN about this kind of thing already:
> >
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox.
>
> > If you would like to update or redo that page with your new work, that
> > would be incredibly excellent.
>
> Yeah, thanks for the pointer - I've contributed to that document over
> the years. I'm not sure the level of detail I'm aiming for is
> appropriate for that general purpose page, but there's an opportunity to
> improve the existing MDN page for sure.
>
> thanks,
>
> --
> Mike Taylor
> Web Compat, Mozilla
>
-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: User Agent Strings in Firefox and their history

[Eric Shepherd (Sheppy)]

We actually have a page on MDN about this kind of thing already:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox.
If you would like to update or redo that page with your new work, that
would be incredibly excellent.

On Thu, Sep 20, 2018 at 12:18 PM Mike Taylor  wrote:

> Hi,
>
> For the past few weeks I've been working on a reference document [1] for
> UA strings in Firefox products, and how they've changed since Firefox 4.
>
> If anyone is interested in these types of things (there's dozens of us),
> and would like to review it and perhaps point out mistakes or things
> I've missed, that would be cool.
>
> At some future point it can get moved from a Google doc to a wiki, or
> MDN or maybe medium.com (kidding).
>
> It should be set up so anyone with the link can add a comment.
>
> [1]
> <
> https://docs.google.com/document/d/1cizvn4wahdfwHUVG_H_Uf15HPBTWyB6GH7j_utHdrKc/edit?usp=sharing
> >
>
> thanks,
>
> --
> Mike Taylor
> Web Compat, Mozilla
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Plan for Sunsetting MozReview

[Eric Shepherd (Sheppy)]

Yes, we have found that and have been using it but as you say, it loses
some of the detail that has been historically helpful when writing
documentation. We eagerly await the redirect tool.

I do have concerns, reading the comments about Phabricator and usability,
but I will wait to comment myself until I've had a chance to really make
use of it, other than to say that the MDN web docs team spends a lot of
time reading through the comments and review notes on bugs, for obvious
reasons. Anything that makes that take longer or involve more clicks and
less convenience makes me really nervous about productivity impact.

On Mon, Aug 27, 2018 at 6:50 PM  wrote:

> (Disclaimer: I'm not from IT!)
>
> Until this gets fixed, a workaround for closed bugs is to go to the bottom
> of the bug, and look for https://hg.mozilla.org/mozilla-central/rev/...
> links.
> Not as pretty, and missing review context, but hopefully this should help
> explore the changed code in most cases.
>
> Cheers,
> Gerald
>
> On Tuesday, August 28, 2018 at 8:17:24 AM UTC+10, Eric Shepherd (Sheppy)
> wrote:
> > We've noticed that attachment links are no longer working because they're
> > still trying to go to reviewboard, and there don't appear to be
> redirects.
> > See for example this bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1211330. It has two
> > attachments. Clicking either one of them gives you a hard-hat page
> instead
> > of the changes.
> >
> > Eric Shepherd
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Plan for Sunsetting MozReview

[Eric Shepherd (Sheppy)]

We've noticed that attachment links are no longer working because they're
still trying to go to reviewboard, and there don't appear to be redirects.
See for example this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1211330. It has two
attachments. Clicking either one of them gives you a hard-hat page instead
of the changes.


On Fri, Jul 27, 2018 at 1:30 PM Mark Côté  wrote:

> To follow up on my follow up, there were some good suggestions on
> dev-platform, so we're going to amend our plan somewhat.
>
> On August 20, we will remove public access to MozReview and move all the
> repositories on hg-reviewboard.mozilla.org to hg.mozilla.org (exact
> location TBD). We will create a simple redirection service that will map
> each of the following:
>
> * review-request diff to appropriate changeset in the review repo on
> hg.mozilla.org
> * review request to associated bug
> * review to the associated BMO comment
>
> Only diffs that have “stub attachments” will be redirected, which means
> the most recent diffs on review requests. This includes any abandoned or
> obsoleted diffs.
>
> This will ensure that all stub attachments redirect to diffs, and that any
> reviewboard.mozilla.org links in docs, browser histories, etc., will
> redirect to equivalent content. It was also preserve any unpublished
> commits that were part of a diff's history.
>
> There is no change to the update-only period from August 6 to August 20.
>
> Mark
>
>
> On Thu, Jul 26, 2018 at 2:37 PM, Mark Côté  wrote:
>
>> To follow up on some previous threads, here is the plan for deprecating,
>> archiving, and decommissioning MozReview.
>>
>> The MozReview shutdown deadline is approaching. Although enhanced
>> commit-series support is still in progress (see update below), MozReview
>> users should start familiarizing themselves with Phabricator now. We have a
>> guide specifically for MozReview users to ease the transition (which will
>> be updated when the commit-series work is finalized):
>> https://moz-conduit.readthedocs.io/en/latest/mozreview-migration-guide.html
>>
>> From August 6 to August 20, use of MozReview will be restricted to
>> updates to existing reviews. In other words, review cycles in progress will
>> be given until August 20 to be completed, but no new commit series will be
>> permitted.
>>
>> On August 20, we will remove public access to MozReview and archive
>> patches. Every landed, in-progress, and abandoned patch will be downloaded
>> from MozReview and stored in an S3 bucket. The “stub attachments” in
>> Bugzilla that currently redirect to MozReview will be updated to link to
>> the appropriate S3 bucket. Review flags and bug comments will be preserved.
>>
>> After archiving is complete and verified, the MozReview servers will be
>> decommissioned.
>>
>> We will also be writing a simple redirection service to map specific
>> MozReview reviews to associated BMO comments, review requests to associated
>> bugs, and review-request diffs to the appropriate S3 buckets. This service
>> will be up shortly after MozReview is decommissioned.
>>
>> We realize and apologize that this is a fairly short timeline; however,
>> the current location of the MozReview servers is in the process of being
>> shut down, and thus it is urgent that we decommission this service soon to
>> allow an orderly exit.
>>
>> As for enhanced support for series of commits in Phabricator, the new
>> command-line interface to submit, update, and apply series (bug 1471678) is
>> currently in review. The first release will support Mercurial only, but
>> git-cinnabar support will follow shortly (the code is designed with it in
>> mind). Work on series support in Lando (bug 1457525) is progressing; we
>> will be posting screenshots of the new UI shortly. It should be ready in
>> 2-3 weeks.
>>
>> Please note that we eventually plan to decommission Splinter as well;
>> however, we know we need some time to work out the kinks in Phabricator.
>> Splinter will remain operational near-term, but we ask everybody to
>> familiarize themselves with Phabricator and file bugs when things don't
>> work. *Please do not wait for Splinter EOL to try Phabricator; we need your
>> feedback before then in order to act on it.*
>>
>> Mark
>>
>>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Eric Shepherd (Sheppy)]

Those notes should also be useful for the docs team if we need to document
this stuff before it makes it into a spec.

On Wed, Aug 15, 2018 at 6:18 PM Mats Palmgren  wrote:

> On 8/14/18 12:52 AM, Jonathan Watt wrote:
> > On 08/08/2018 21:08, Boris Zbarsky wrote:
> >> Are we writing down something that could get turned into a spec?
> >
> > I've got a bunch of messy notes that I hope will be of some use for
> that, but
> > no, so far I have not attempted to create draft spec text to replace the
> text in
> > CSS UI 4.
>
> It'd be awesome if you could write this down somewhere while you
> have the details somewhat fresh in your mind.  I'd be happy to
> contribute what I know about this too.
>
> Those notes would be an excellent starting point for a discussion
> with other vendors about speccing this property, which I believe
> is necessary if we're going to converge UAs to something that
> is "compatible".
>
>
> /Mats
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: Shadow DOM and Custom Elements

[Eric Shepherd (Sheppy)]

I, for one, would like to say: "Huzzah!"

On Fri, Aug 10, 2018 at 4:54 PM,  wrote:

> On Friday, August 10, 2018 at 5:49:31 PM UTC+3, smaug wrote:
> > I'm planning to keep Shadow DOM and Custom Elements turned on on
> beta/release builds.
> > Target release is Firefox 63.
> > prefs are dom.webcomponents.customelements.enabled and
> dom.webcomponents.shadowdom.enabled.
> >
> > Custom elements has been enabled in Nightly since January and Shadow DOM
> since late May.
> >
> > Bugs:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1471947 (Shadow DOM)
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1471948 (Custom Elements)
> >
> > Even though the APIs are totally distinct, web pages expect either
> neither be there or both, so they
> > need to ship together.
> >
> >
> >
> > -Olli
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

[Eric Shepherd (Sheppy)]

Thank you; that will help the docs team very much as well.

On Tue, Aug 7, 2018 at 11:30 AM, Boris Zbarsky  wrote:

> On 7/30/18 8:03 PM, Kip Gilbert wrote:
>
>> Link to standard:
>>
>
> Kip,
>
> Could you please ensure that all the relevant .webidl files have links to
> the relevant bits of the standard at the top of the file (and on the
> individual interface definitions if there are multiple interfaces in the
> file)?  See Navigator.webidl for an example of what I'm talking about.
> Right now our WebVR IDLs do not have such links, and that makes working
> with those files a lot more difficult and error-prone than it really should
> be.
>
> The api is documented on the immersive-web GitHub page:
>>
>> https://immersive-web.github.io/webxr/ <https://immersive-web.github.
>> io/webxr/>
>>
>
> Is this meant to replace the existing WebVR APIs or augment them? Sounds
> like replace in the long term?
>
> Final TAG review and W3C Working Group discussion may result in late
>> breaking changes.  These changes are expected to affect the syntax of the
>> API and not the general behaviour.  Any changes are expected to be
>> identified before our implementation is ready to ship to release.
>>
>
> Sounds great.  :)
>
> -Boris
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Prioritizing media documentation

[Eric Shepherd (Sheppy)]

Hey everyone... I'm working on trying to get our media documentation fully
up to date and could use five minutes or so of time from anyone with an
interest in these APIs:

   - WebRTC
   - Media Capture and Streams API
   - Media Recording API
   - Web Audio API
   - The  and  elements and the HTMLMediaElement based
   interfaces

I've created a brief survey asking for your input prioritizing the
remaining work to be done on these documentation sets. The more input I
get, the more sure I can be to get the most useful and important stuff done
first.

So if you use (or want to use) any of these APIs, or if you're an engineer
helping to build these APIs, *please* find five minutes or so to do this
poll so I can use that information to finish planning my deliverables for
the second half of the year.

The survey is located here: https://goo.gl/forms/lno9LqANaNXdXG9s1

Thank you in advance to anyone who helps. Your input will help to ensure
MDN's media documentation becomes the best in the world!

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ standards proposal for a embedding library

[Eric Shepherd (Sheppy)]

Yeah, a standard web_vew library being part of the C++ standard is not a
good idea. It's far too huge a thing with far too many potential pitfalls
and dangerous consequences, and is an overweight solution to what should be
a comparatively lightweight problem.

If the goal is just to have a standard way to build basic GUI interfaces in
C++, then it might make more sense to do something like adopt Tk as a UI
language for C++. It's reasonably well-known, is both expansive and easy to
use, and is designed specifically for creating UIs for integration into
apps in other languages, with cross-platform compatibility baked in.

If the goal is a high-speed graphics solution of some sort, it seems like
adopting a standard such as OpenGL ES as the standard for baseline graphics
in C++ would be more logical. It's already a standard, it's well-documented
and well-known, and in most cases you can shunt off the majority of work to
a platform runtime.


On Mon, Jul 30, 2018 at 3:00 PM, Myk Melez  wrote:

> Botond Ballo wrote on 2018-07-18 09:45:
>
>> As we have some experience in the embedding space here at Mozilla, I
>> was wondering if anyone had feedback on this embedding library
>> proposal. This is an early-stage proposal, so high-level feedback on
>> the design and overall approach is likely to be welcome.
>>
> I'm afraid that I agree with the consensus in this thread: specifying a
> web_view class isn't a useful activity for the C++ standards committee to
> undertake.
>
> The proposal notes that C++ specifies "no useful facilities" for creating
> graphical interfaces, so "users either need to make use of system-specific
> APIs, third-party libraries, or move to a different programming language."
>
> However, it doesn't explain why "system-specific APIs" and "third-party
> libraries" are considered insufficient or harmful. As others have pointed
> out, for languages with first-class modules and package ecosystems,
> third-party libraries are a feature of a language, not a bug. And
> "system-specific APIs" have their own advantages (along with downsides).
>
> The proposal also notes, "To be useful, we’ll need to require support for
> a large number external standards (i.e., [X]HTML, CSS, SVG, ECMAScript, and
> possibly others). Our three-year release cycle is likely sufficient to
> maintain a proper list of such standards, but it’s still a large list, and
> to be clear, the transitive closure of this list is huge."
>
> At the very least, this statement is worthy of more careful consideration,
> given the ongoing rapid change in the web platform surface area (not to
> mention implementation strategies that affect embedding APIs, such as the
> move to multiple content processes).
>
> And it notes, "Surveying the current implementations has convinced me that
> this kind of interface is appropriate for standardization, at least in the
> sense that, while broadly useful, using these services from a C++
> application today requires difficult-to-get-right platform-specific code.
> Moving that burden to C++ library implementers, as a result, makes sense."
>
> The former statement may be true, but the latter doesn't necessarily
> follow; and it isn't even clear that the former is true. The author himself
> demonstrates a prototype implementation that supports multiple platforms.
> And the Chromium Embedded Framework (CEF) has similarly long provided a
> cross-platform API for embedding the web into C++ applications.
>
> Don't such third-party libraries show that it *is* possible to use the web
> in a C++ application without "difficult-to-get-right platform-specific
> code"?
>
> (It might be that developing such a cross-platform library is itself
> challenging, but that's a burden on library vendors, not application
> developers.)
>
> Cross-platform graphical application development with C++ can be
> challenging, and the web may be a solution in some cases. Indeed, Mozilla
> itself has faced that challenge and used its own web implementation to help
> solve it for desktop platforms. And others have solved it via third-party
> libraries and system-specific APIs.
>
> Nevertheless, while those implementations are imperfect, and there's
> plenty of scope for improvement, a minimal standard that evolves more
> slowly than the web and its implementations seems like it would do more
> harm than good. And thus a web_view class isn't well-suited for
> specification by the C++ standards committee.
>
> -myk
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: application/json mime type support for OpenSearch Suggestions

[Eric Shepherd (Sheppy)]

Is there a bug number for this? I was not able to find one.

On Wed, Jun 20, 2018 at 5:40 AM, Mark Banner  wrote:

> In the draft OpenSearch specifications [1], there is ambiguity of the
> required mime type for providing suggestions for search providers.
>
> Currently, the Suggestions extension [2] specifies
> "application/x-suggestions+json", however the example given in the main
> specification uses "application/json".
>
> Since subtypes of json are typically no longer used, it seems reasonable
> to support both "application/x-suggestions+json" and "application/json".
>
> Target Release: Firefox 63
>
> Other browser support: Edge supports both, Chrome only supports
> "application/x-suggestions+json" at this time.
>
>
> [1] https://github.com/dewitt/opensearch/blob/master/opensearch-
> 1-1-draft-6.md#the-url-element
>
> [2] http://www.opensearch.org/Specifications/OpenSearch/Extensio
> ns/Suggestions#URL_elements
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Eric Shepherd (Sheppy)]

Thanks for sharing that overview!

Although I can see why there's a lot of resistance to adding a graphics
library to the C++ standard, it seems to me like a good idea. Even though,
yes, there are going to be better and faster libraries out there, it's also
true that anyone looking to maximize performance is going to be bypassing
parts of the standard runtime anyway. Even text-based applications often
bypass the standard I/O library to do their output more directly to the
console (as I think back to my days of directly blasting characters into
the text screen's video memory). Math routines are often replaced with
custom libraries that do things faster, either using better algorithms,
making use of processor features not directly supported by the standard
library, or by making accuracy concessions when all you need are "good
enough" values.

A standard graphics library would serve to make it easier for new
programers to onboard, would be great for quick tools that graph the
results of a problem being solved, or even many simple or low-intensity
applications that simply don't need high-performance graphics.

I do think that parts of the proposal could be broken off into separate
components. The linear algebra stuff, along with geometry, could be split
out into a separate proposal, since these have uses beyond 2D graphics.
This would both help bring other capabilities to light sooner, but would
lighten up the graphics proposal as well.


On Wed, Jun 20, 2018 at 11:29 AM, Botond Ballo  wrote:

> My blog post about what happened at this meeting is now live:
>
> https://botondballo.wordpress.com/2018/06/20/trip-report-c-
> standards-meeting-in-rapperswil-june-2018/
>
> Cheers,
> Botond
>
>
> On Tue, May 22, 2018 at 6:35 PM, Botond Ballo  wrote:
> > Hi everyone!
> >
> > The next meeting of the C++ Standards Committee will be June 4-9 in
> > Rapperswil, Switzerland.
> >
> > This is going to be a pivotal meeting, with go / no-go decisions
> > expected for several highly-anticipated C++20 features, including a
> > subset of Modules; Coroutines; Ranges; and "natural syntax" Concepts /
> > abbreviated function templates. A discussion of whether or not to
> > continue efforts to standardize 2D Graphics is also scheduled (see
> > arguments for [1] and against [2]). In addition, work will continue on
> > various Technical Specifications that are in flight (including,
> > notably, Reflection), and processing the large influx of new language
> > and library feature proposals.
> >
> > If you're curious about the state of C++ standardization, I encourage
> > you to check out my blog posts where I summarize each meeting in
> > detail (most recent one here [3]), and the list of proposals being
> > considered by the committee (new ones since the last meeting can be
> > found here [4] and here [5]).
> >
> > I will be attending this meeting, hanging out in the Evolution Working
> > Group (where new language features are discussed at the design level)
> > as usual. As always, if there's anything you'd like me to find out for
> > you at the meeting, or any feedback you'd like me to communicate,
> > please let me know!
> >
> > Finally, I encourage you to reach out to me if you're thinking of
> > submitting a proposal to the committee. I'm always happy to help with
> > formulating and, if necessary, presenting a proposal.
> >
> > Cheers,
> > Botond
> >
> >
> > [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0988r0.pdf
> > [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html
> > [3] https://botondballo.wordpress.com/2018/03/28/trip-report-c-
> standards-meeting-in-jacksonville-march-2018/
> > [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#
> mailing2018-02
> > [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#
> mailing2018-04
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to request documentation for new features or report problems on MDN

[Eric Shepherd (Sheppy)]

It's also worth noting that you should feel free to add the dev-doc-needed
keyword to any bug you think even *might* affect developer documentation.
We would rather have false positives than miss something that should have
been updated.

As an example, perhaps you add code to improve the internal design of how
some stuff works, and add some beefed up error management to it. That's
worth adding dev-doc-needed to if there's any chance that a new exception
might bubble up to web developers. At the face of it, internal cleanup work
might not seem relevant, but there are times when it is, so it's helpful to
be aware of that -- because cases like this are a lot less likely that we
on the writing team will find on our own.


On Thu, May 17, 2018 at 6:11 AM, Chris Mills <cmi...@mozilla.com> wrote:

> Yes, what sheppy said ;-)
>
> Chris Mills
> MDN content lead & writers' team manager || Mozilla
> developer.mozilla.org || MDN Web Docs
> cmi...@mozilla.com || @chrisdavidmills
>
> > On 17 May 2018, at 05:27, Eric Shepherd (Sheppy) <esheph...@mozilla.com>
> wrote:
> >
> > Yes. Always, you're welcome to make needed changes yourself. If you want
> a writer to take a look after you're done, to be sure everything is in the
> right place (or to double-check your grammar), that's certainly no problem.
> >
> > On Wed, May 16, 2018 at 6:40 PM Martin Thomson <m...@mozilla.com> wrote:
> > Hi Chris,
> >
> > I assume that "just fix it" is still a viable alternative to the
> processes
> > you describe.  For small things, that might be easier for all involved.
> > On Thu, May 17, 2018 at 5:39 AM Chris Mills <cmi...@mozilla.com> wrote:
> >
> > > Hi all,
> >
> > > I am sending a mail around to explain how to request MDN documentation
> > for new features you are working on (e.g. new web platform features, web
> > extensions features, devtools features), or report docs problems. We've
> had
> > a fair few people show a misunderstanding of how this process works
> > recently.
> >
> > > TL;DR
> > > -
> >
> > > There are two main ways to ask for docs on MDN:
> >
> > > * Requesting docs by adding the "dev-doc-needed" keyword to an
> > engineering bug
> > > * Reporting problems by filing a bug against the "Developer
> > Documentation" product (
> > https://bugzilla.mozilla.org/enter_bug.cgi?product=
> Developer%20Documentation
> > )
> >
> > > They are not equivalent.
> >
> > > * "dev-doc-needed" means "some code in Firefox has changed, and as a
> > result the docs need to be updated"
> > > * a "Developer Documentation" bug means "some docs on MDN are
> > wrong/misleading/incomplete"
> >
> > > Requesting docs
> > > ---
> >
> > > So, if you are working on a bug to add a new feature or update an
> > existing feature, and it will require documentation changes, add the
> > keyword "dev-doc-needed" to it. This keyword doesn't mean "we will
> document
> > this NOW". It means "we will document this in the future, when
> appropriate".
> >
> > > The way the system works is that when "dev-doc-needed" is put on a bug,
> > as soon as that bug is then resolved our system picks it up and then we
> > will act on it as appropriate (by documenting the feature, or maybe just
> > ignoring it if it was WONTFIX’ed, etc.)
> >
> > > Using this system, we are ready to document new features, if and when
> > they are needed. Please add "dev-doc-needed" for any such features you
> are
> > working on. It makes our lives much easier. Thanks!
> >
> > > Note: You can set "dev-doc-needed" any time, but we will only look at
> it
> > once the bug it's attached to is resolved. Once the bug is resolved we'll
> > schedule time to update the docs for it, always aiming to have the docs
> > updated before the version of Firefox containing the change is released
> > (hopefully before that Firefox is in beta, but we don't always manage
> that).
> >
> > > Note: Feature removal/unship bugs should also have "dev-doc-needed"
> added
> > — these are still changes that require docs updates.
> >
> > > Note: We don't add notes in our docs to cover bugs/regressions that
> crop
> > up. These are often shortlived, and we don't have the bandwidth for this.
> >
> > > Reporting problems
> > > --
> >
> > > If you notice a problem of some kind with an MDN doc, 

Re: How to request documentation for new features or report problems on MDN

[Eric Shepherd (Sheppy)]

Yes. Always, you're welcome to make needed changes yourself. If you want a
writer to take a look after you're done, to be sure everything is in the
right place (or to double-check your grammar), that's certainly no problem.

On Wed, May 16, 2018 at 6:40 PM Martin Thomson <m...@mozilla.com> wrote:

> Hi Chris,
>
> I assume that "just fix it" is still a viable alternative to the processes
> you describe.  For small things, that might be easier for all involved.
> On Thu, May 17, 2018 at 5:39 AM Chris Mills <cmi...@mozilla.com> wrote:
>
> > Hi all,
>
> > I am sending a mail around to explain how to request MDN documentation
> for new features you are working on (e.g. new web platform features, web
> extensions features, devtools features), or report docs problems. We've had
> a fair few people show a misunderstanding of how this process works
> recently.
>
> > TL;DR
> > -
>
> > There are two main ways to ask for docs on MDN:
>
> > * Requesting docs by adding the "dev-doc-needed" keyword to an
> engineering bug
> > * Reporting problems by filing a bug against the "Developer
> Documentation" product (
>
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Documentation
> )
>
> > They are not equivalent.
>
> > * "dev-doc-needed" means "some code in Firefox has changed, and as a
> result the docs need to be updated"
> > * a "Developer Documentation" bug means "some docs on MDN are
> wrong/misleading/incomplete"
>
> > Requesting docs
> > ---
>
> > So, if you are working on a bug to add a new feature or update an
> existing feature, and it will require documentation changes, add the
> keyword "dev-doc-needed" to it. This keyword doesn't mean "we will document
> this NOW". It means "we will document this in the future, when
> appropriate".
>
> > The way the system works is that when "dev-doc-needed" is put on a bug,
> as soon as that bug is then resolved our system picks it up and then we
> will act on it as appropriate (by documenting the feature, or maybe just
> ignoring it if it was WONTFIX’ed, etc.)
>
> > Using this system, we are ready to document new features, if and when
> they are needed. Please add "dev-doc-needed" for any such features you are
> working on. It makes our lives much easier. Thanks!
>
> > Note: You can set "dev-doc-needed" any time, but we will only look at it
> once the bug it's attached to is resolved. Once the bug is resolved we'll
> schedule time to update the docs for it, always aiming to have the docs
> updated before the version of Firefox containing the change is released
> (hopefully before that Firefox is in beta, but we don't always manage
> that).
>
> > Note: Feature removal/unship bugs should also have "dev-doc-needed" added
> — these are still changes that require docs updates.
>
> > Note: We don't add notes in our docs to cover bugs/regressions that crop
> up. These are often shortlived, and we don't have the bandwidth for this.
>
> > Reporting problems
> > --
>
> > If you notice a problem of some kind with an MDN doc, such as a doc that:
>
> > * should really be added to make a resource complete, but is not linked
> to a specific feature addition
> > * is located in the wrong place
> > * contains a code, spelling or grammar error
> > * looks outdated
> > * contains spam
> > * etc.
>
> > Please file a new bug to report it, under the "Developer Documentation"
> product.
>
> > We triage these bugs weekly, and prioritise and handle them in a similar
> kind of way to engineering bugs.
>
> > Important: Don't file "Developer Documentation" bugs for feature
> additions that already being tracked in an engineering bug. Instead, add
> the "dev-doc-needed" keyword to the engineering bug. We've had a few
> duplications recently because of this.
>
> > Many thanks!
>
> > Chris Mills
> > MDN content lead & writers' team manager || Mozilla
> > developer.mozilla.org || MDN Web Docs
> > cmi...@mozilla.com || @chrisdavidmills
>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is super-review still a thing?

[Eric Shepherd]

It seems that, yes, a model in which a patch to a given component would
need reviews by any one person in a specific pool of reviewers makes a lot
of sense. Even more so if the patch submitter doesn't have to figure out
who is in the pool.

Having a mechanism that supports a secondary, high-level review for cases
involving a lot of interrelated patches, architectural changes, UX updates,
etc. would also make a lot of sense. Call it a meta-review, perhaps; as in
reviewing a meta bug's set of changes.

-- 
Eric Shepherd
Senior Technical Writer
Mozilla Developer Network
https://developer.mozilla.org/
Blog: http://www bitstampede.com/
Twitter: https://twitter.com/sheppy


On May 10, 2018 at 11:15 AM, Gregory Szorc <gsz...@mozilla.com> wrote:



On May 10, 2018, at 06:47, Randell Jesup <rje...@jesup.org> wrote:

On Thu, Apr 26, 2018, at 12:41 AM, Mark Côté wrote:
How we might use blocking reviewers in our workflow is still open, but
it could be used for training up reviewers, in which case the trainee
would be a regular reviewer and the module peer/owner would be a
blocking reviewer.


It's not uncommon for me to submit patches for review from multiple people
where I require all reviewers to sign off on the patch, usually because I
ask them to look at different parts of the patch. I don't think I have
ever sent a patch to get review from more than one person with the
intention of landing it if only one person OKs it. (I'd probably needinfo
people to get that kind of feedback.) So ignoring potential new workflows
like the training one you mention, I think I would exclusively use blocking
reviewers. It's good to know that Phabricator will help me avoid
accidentally landing patches when not all of my reviewers have signed off.


Agreed... but it sounds like they're not quite sure how this will be
used. I'm concerned that developers may be confused and just as for
review by N people, not realizing it can be landed when one of them
r+'s. (Especially if the developer doesn't frequently use multiple
reviewers.) At minimum, if this how it works, there will been to be
clear communication about when to use this - or (better!) to switch the
default to blocking, and have the unusual/more-work-to-ask-for case be
any-of.

Once in a blue moon I'll ask for a fast review from any of N people,
then cancel the r?'s once i have 1 r+. but this is really rare, and
mostly when there's a time deadline to land something ASAP (sec issue,
or to get in ahead of a merge date). 99% of the time when I ask for N
people, I need r+ from all of them.

On the other side, I do know that the build peers (IIRC) us a shared
reviewing setup, where most bugs are thrown in a pool for any of them to
review. But that's not the normal workflow for any other group I know
of in Mozilla, at least in Firefox. (I don't know them all, though.)


When you take a step back, I think you have to conclude that our current
model of requesting reviews from *individuals* is not practical for the
common case. The way our code governance model works is that groups of
people (module members) are empowered to sign off on changes. But because
existing review tooling (practically speaking) only allows assigning
reviews to individuals (as opposed to a group consisting of module
members), that’s what we do. I.e. tools are dictating sub-optimal workflows
that don’t match our governance model.

In the common case, I think group assignment is preferred. Maybe it assigns
to an available person at submission time. But the submitter should not
need to be burdened with picking an individual. (This picking requirement
is especially hostile to new contributors who don’t know who to pick for
review.)

Phabricator has the concept of a normal “reviewer” and a “blocking
reviewer.” “Blocking” means they must sign off before the review is marked
as accepted.

I think the world we’ll eventually get to is one where most reviews are
assigned to groups (ideally automatically by mapping files changed to
appropriate reviewers) as normal non-blocking reviewers in Phabricator. For
special cases, we can assign individuals for review and/or set “blocking
reviewers” so someone or a member of a group *must* sign off. The review
submission tooling should make all of this turnkey - allowing people to
easily opt in to the special case if warranted. But most review requirement
policies should be codified so tools can apply/enforce them without human
intervention.

It’s worth noting that in a future world where the review tool isn’t
constraining us to assigning reviews to individuals and where group
assignment is the default, assignments to individuals may represent
shortcomings in the distribution of expertise. I.e. if only one person is
capable of performing a review, then we have a bus factor of 1 and there is
a business continuity concern. Assigning reviews to groups - perhaps
specialized groups like “dom experts” instead of the normal “dom peers”
group - helps reinforce th

Re: Intent to ship: Allow the overflow shorthand to accept two values.

[Eric Shepherd (Sheppy)]

Yay! This will resolve an issue I filed on the spec, so that's a happy day
for me. :)

On Wed, Apr 11, 2018 at 3:42 AM, Emilio Cobos Álvarez <emi...@crisal.io>
wrote:

> Hi,
>
> In bug 1453148 I'm planning to implement the CSSWG resolution at:
>
>   https://github.com/w3c/csswg-drafts/issues/2484
>
> It's a very uncontroversial change that doesn't change backwards compat,
> and makes the shorthand more consistent. But it was probably worth an
> intent.
>
> WPT tests are being added as part of that bug. Let me know if there's
> any concern with proceeding here, thanks!
>
>  -- Emilio
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Components and QueryInterface can no longer be used in non-system globals

[Eric Shepherd (Sheppy)]

Ironically, the timing is impressive here. I just this morning noticed that
the tables of inheritance we have in JSON for APIs includes
LegacyQueryInterface among the mixins implemented by a number of
interfaces, and was already in the process of creating a PR to remove that
since it should never have been included in the first place for open web
docs, really.

On Mon, Mar 26, 2018 at 1:55 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> I have just landed changes on inbound that restrict WebIDL QueryInterface
> [1] and the Components object [2] to system scopes.
>
> There are two caveats:
>
> 1)  The Components bit is not fully enforced by the security
> infrastructure yet, but those patches are coming in the next day or so. [3].
>
> 2)  "system" in this case includes things that do enablePrivilege.  The
> only consumer blocking this being removed is Talos...
>
> -Boris
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1448397
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1448735 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1448736
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1389585 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1389581
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of "remote XUL"

[Eric Shepherd (Sheppy)]

I would agree that going all-out and disabling remote XUL entirely makes
the most sense, except in the cases you mention.

The one potential exception: would it make sense to allow it to be enabled
(with it disabled by default) on copies of Firefox set up with Policy
Engine, to allow those users the option?

On Tue, Mar 27, 2018 at 11:36 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> Background: We currently have various provisions for "remote XUL", wherein
> a hostname is whitelisted to:
>
> 1)  Allow parsing XUL coming from that hostname (not normally alllowed for
> the web).
>
> 2)  Allow access to XPConnect-wrapped objects, assuming someone hands out
> such an object.
>
> 3)  Run XBL JS in the same global as the webpage.
>
> 4)  Allow access to a "cut down" Components object, which has
> Components.interfaces but not Components.classes, for example.
>
> This machinery is also used for the "dom.allow_XUL_XBL_for_file"
> preference.
>
> The question is what we want to do with this going forward.  From my point
> of view, I would like to eliminate item 4 above, to reduce complexity.  I
> would also like to eliminate item 2 above, because that would get us closer
> to having the invariant that XPConnect is only used from system
> principals.  These two changes are likely to break some remote XUL
> consumers.
>
> The question is whether we should just go ahead and disable remote XUL
> altogether, modulo its usage in our test suites and maybe
> "dom.allow_XUL_XBL_for_file" (for local testing).  It seems like that might
> be clearer than a dribble of breakage as we remove bits like items 2/4
> above, slowly remove various bindings, slowly remove support for some XUL
> tags, etc...
>
> Thoughts?  My gut feeling is that we should just turn off remote XUL
> outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file"
> case.
>
> -Boris
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

[Eric Shepherd (Sheppy)]

I definitely see some easy ways this could be problematic from a public
relations perspective given things going on in the industry these days and
some of our own mistakes the in the past. It's definitely worth taking a
little while to consider the implications before throwing the switch.

On Sun, Mar 18, 2018 at 8:39 PM, Dave Townsend <dtowns...@mozilla.com>
wrote:

> On Sun, Mar 18, 2018 at 5:27 PM Patrick McManus <pmcma...@mozilla.com>
> wrote:
>
> > Obviously, using a central resolver is the downside to this approach -
> but
> > its being explored because we believe that using the right resolver can
> be
> > a net win compared to the disastrous state of unsecured local DNS and
> > privacy and hijacking problems that go on there. Its just a swamp out
> there
> > (you can of course disable this from about:studies or just by setting
> your
> > local trr.mode pref to 0 - but this discussion is meaningfully about
> > defaults.)
> >
>
> I believe that a good resolver makes all the difference. I'm just concerned
> about the privacy aspects of this, particularly since we're not really
> messaging this to users. Is there a reason we need a full 50% of Nightly
> population to get the data we need here?
>
> On that topic I'm interested in what data we expect to get, is it just
> comparing how the resolver performs from a variety of locations and for a
> variety of lookups?
> Is there some mechanism in place for users who's normal DNS resolver
> intentionally returns different results to global DNS (e.g. for region
> spoofing etc.)?
>
>
> > And in this case the operating agreement with the dns provider is part of
> > making that right choice. For this test that means the operator will not
> > retain for themselves or sell/license/transfer to a third party any PII
> > (including ip addresses and other user identifiers) and will not combine
> > the data it gets from this project with any other data it might have. A
> > small amount of data necessary for troubleshooting the service  can be
> kept
> > at most 24 hrs but that data is limited to name, dns type, a timestamp, a
> > response code, and the CDN node that served it.
> >
>
> Not retaining IP addresses is good. Can they perform aggregate tracking of
> hostname requests, or tie common hostname requests from an origin together
> somehow? What is our recourse if they break this agreement (the recent
> Facebook debacle seems likely to make folks jumpy).
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ci, Cr, Cc, and Cu are now automatically defined in all chrome scopes

[Eric Shepherd (Sheppy)]

That's... brilliant. How did it take this many years for that to come up? :)

Sheppy

On Thu, Feb 1, 2018 at 5:11 PM, Andrew McCreight <amccrei...@mozilla.com>
wrote:

> Bug 767640 just merged to mozilla-central. This patch makes it so that Ci,
> Cr, Cc, and Cu are automatically defined in any chrome scope that has a
> Components object. Rejoice, because you no longer need to add "var Ci =
> Components.interfaces" into every file.
>
> I have a followup bug, bug 1432992, that removes almost all of the existing
> definitions of these variables.
>
> Andrew
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Unship: stream decoder for BinHex format

[Eric Shepherd (Sheppy)]

Man… It’s weird that this makes me all nostalgic. :)


Eric Shepherd
Senior Technical Writer, MDN
MDN: https://developer.mozilla.org/
Blog: https://www.bitstampede.com/

On October 18, 2017 at 8:50:20 AM, Joshua Cranmer  (pidgeo...@gmail.com)
wrote:

FWIW, I've considered ripping out the binhex decoding from mailnews code
anyways.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship version 4 of the Safe Browsing protocol

[Eric Shepherd (Sheppy)]

On August 18, 2017 at 2:57:13 AM, Mike Hommey (m...@glandium.org) wrote:

On Wed, Aug 16, 2017 at 12:43:19PM -0700, Daniel Veditz wrote:
> 100 options is 4950 configurations to test.

I think you mean 2^100. That's 1.26 x 10^30.

Also known as “a boatload.”



Eric Shepherd
Senior Technical Writer, MDN
MDN: https://developer.mozilla.org/
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship throttling of tracking timeouts

[Eric Shepherd (Sheppy)]

Thank you for the details. I’ve added dev-doc-needed on the bug and added a 
link to this thread so the writer can find the information here quickly.

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: https://twitter.com/sheppy

> On May 11, 2017, at 11:32 PM, Bill McCloskey <wmcclos...@mozilla.com> wrote:
> 
> (I hope everything I've said is correct. I've been following the change but
> I had nothing to do with the code.)

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

Re: Intent to Ship throttling of tracking timeouts

[Eric Shepherd (Sheppy)]

So part of private browsing and not a developer-facing feature, then?

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: https://twitter.com/sheppy

> On May 11, 2017, at 1:40 PM, Andreas Farre <fa...@mozilla.com> wrote:
> 
> Timeouts classified using privacy.trackingprotection.annotate_channels as
> coming from a tracking script.

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

dev-platform@lists.mozilla.org

[Eric Shepherd]

We’re updating the  element’s documentation to not suck (yay!) and I’ve 
run into this: the WHATWG spec doesn’t currently list “datetime” as a valid 
type; only “datetime-local” is listed. Normally, MDN treats WHATWG as 
canonical, rather than W3C, but we do peek at that as well.

I’m pretty certain that this is correct; that “datetime” is deprecated. 
However, I do want to confirm things, since something odd turned up: W3C’s HTML 
5.1 spec doesn’t include “datetime”, it’s present in the latest 5.2 draft. So 
apparently it was only recently even added to HTML by W3C. What’s the actual 
status of datetime?

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: https://twitter.com/sheppy

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

Re: Deprecating XUL in new UI

[Eric Shepherd]

Certainly given that there are already several projects that use HTML to build 
desktop and mobile app UIs, standardizing ways to use HTML to represent any 
missing parts of a desktop UI would be a worthwhile endeavor.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/ <http://www.bitstampede.com/>
Twitter: http://twitter.com/sheppy <http://twitter.com/sheppy>

> On Jan 24, 2017, at 2:36 AM, zbranie...@mozilla.com wrote:
> 
> I can totally imagine us doing it for HTML.

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

Re: Intent to disable service workers and push in 52 ESR

[Eric Shepherd]

Any time something is disabled or removed from ESR, please be sure the 
developer docs team knows about it, because that’s something that has to be 
reflected in our documentation. I’m not aware of many (if any) documentation 
that says something exists in version X but not in ESR version X; that’s an 
inaccuracy we need to avoid and to fix where already present.

> On Jan 18, 2017, at 10:49 AM, Ben Kelly  wrote:
> 
> Hi all,
> 
> I'd like to disable service workers in 52 ESR.  This would also require
> disabling push notifications.
> 
> A year ago we decided to disable service workers in 45 ESR because it was
> very new and unstable:
> 
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/yuNHtDhl3lY/VWXOa8N9AgAJ
> 
> While things have stabilized since then we are in process of making a major
> architectural change in order to support multiple content processes
> (multi-e10s).  This will make it very difficult to uplift fixes.  Once the
> new architecture has stabilized we should be able to enable SW in the next
> ESR.
> 
> Thoughts?
> 
> Thanks.
> 
> Ben
> ___
> 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: Deprecating XUL in new UI

[Eric Shepherd]

It seems to me that the XUL to HTML transition is a big job that needs to be 
done with care. Would it make sense to try to work toward additions to HTML 
and/or additions of prefixed attributes and the like to add the needed 
behaviors to HTML wherever possible before trying to hack out a transition?

It seems to me, anyway, that the ideal solution would be to enhance HTML 
(ideally in the spec) with the features needed to build a full-fledged desktop 
UI. That would be fabulous not just for Firefox making the transition to 
defining its UI in HTML, but could potentially be adopted by other projects and 
platforms that use JavaScript and HTML to build apps (such as Electron).

If we can set a goal of getting a list of the features needed and spec out how 
we’d revise HTML to support those same functionalities (or at least 
functionalities that will get the job done), it would be good for everyone.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/ <http://www.bitstampede.com/>
Twitter: http://twitter.com/sheppy

> On Jan 23, 2017, at 11:12 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> 
> On 1/23/17 10:31 AM, David Bolter wrote:
>> Should (can) it die in the Quantum development timeframe?
> 
> In my opinion, no.
> 
>> What does that do to shipping risk?
> 
> Makes it super-high.
> 
>> I realize churn creates risk, but I seem to recall XBL
>> is getting in the way for Quantum styling?
> 
> Not as much as having to rewrite all our in-tree XBL in not-yet-existing 
> technologies would get in the way...
> 
> -Boris
> 
> ___
> 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: Emoji and Bugzilla

[Eric Shepherd]

Yeah, we’re *so* going to start seeing bugs that are done entirely in emoji. I 
don’t look forward to decoding them, although I’m sure they’ll be incredibly 
clever and fun. :)


> On Jan 17, 2017, at 10:01 PM, Emma Humphries  wrote:
> 
> As the BMO team announced earlier, we're going to be allowing emoji in user 
> inputs in Bugzilla.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1253535 
> 
> 
> We have not committed to a date to release this feature as it requires a 
> production database change which we haven't been able schedule yet. 
> 
> Meanwhile, this change means that as an Bugzilla API consumer, you will need 
> to be ready to accept emoji in your systems.
> 
> In particular, if your client application uses MySQL, you'll need to update 
> your databases and tables to use utf8mb4 instead of utf8 encoding, otherwise 
> if you try writing strings containing emoji, they would be truncated at the 
> first emoji which would be a  situation. Adjust that caveat as needed for 
> other data stores such as Postgres.
> 
> If your application will need time to be able to support emoji, please 
> contact the bmo team. Otherwise we'll assume you're  with this change and 
> not .
> 
> Also, once we turn this feature on, some of our users will think themselves 
> clever and create bugs with  as the title. If the bug contains little else 
> than that, it's probably a  and can be closed as INVALID.
> 
> -- Emma ()
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

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

Re: What are your use cases for the Touch Bar on the new MacBook Pro?

[Eric Shepherd]

I can think of many potential use cases; some are small and others are larger 
and more involved.

I’d love to be able to have WebExtensions be able to add widgets (or even 
simple buttons) to the Touch Bar. It might also be helpful if the developer 
tools could be exposed there, if the developer chooses to do so. I’ve posted a 
long list on one of the Touch Bar related bugs, so I’ll just drop those two 
thoughts here for now. :)

> On Jan 3, 2017, at 12:17 PM, Stephen A Pohl <sp...@mozilla.com> wrote:
> 
> We are gathering ideas for possible use cases of the Touch Bar on the
> new MacBookPro and would like to hear from you! What would improve your
> workflow? What would help our users?
> 
> We will develop[1] a solid 1.0 API around the top features to get the
> ball rolling and will iterate on these going forward.
> 
> Apple has outlined guidelines and best practices[1] for the Touch Bar
> that are good to keep in mind. Here are some of the most important
> points to consider:
> 1. Design a contextual experience. Make the Touch Bar relevant to the
> current context on the main screen.
> 2. Use the Touch Bar as an extension of the keyboard and trackpad, not
> as a display.
> 3. **Don’t expose functionality solely in the Touch Bar.
> 4. Avoid using the Touch Bar for tasks associated with well-known
> keyboard shortcuts.
> 
> -Stephen
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1313455
> [2]
> https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/AbouttheTouchBar.html#//apple_ref/doc/uid/2957-CH104-SW1
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform


Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/
 <http://www.bitstampede.com/>Twitter: http://twitter.com/sheppy 
<http://twitter.com/sheppy>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Iterable declarations on NodeList and DOMTokenList

[Eric Shepherd]

Noted dev-doc-needed on the bug.

Gentle reminder for everyone to try to remember to put this on any bug
which affects how developers can or should use things. :)


*From:* Boris Zbarsky
*Sent:* Friday, Jul 29, 2016 10:41:16 PM EDT
*To:* dev-platform@lists.mozilla.org
*Subject:* Intent to implement and ship: Iterable declarations on
NodeList and DOMTokenList

> Summary: The idea is to have keys/entries/values/forEach methods on
> these two interfaces, so you can do things like:
>
>   document.querySelectorAll("whatever").forEach(someFunc)
>
> and
>
>   document.body.classList.forEach(someFunc)
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1290636

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: KeyboardEvent question for docs update

[Eric Shepherd]

Clearly the information is valuable to have on MDN, judging from these
responses, so I'll go ahead and keep it. I'll try to remember to follow
up here when I'm done so I can get some feedback on the results.

Thanks!


*From:* James Graham
*Sent:* Tuesday, Jul 12, 2016 9:58:57 AM EDT
*To:* dev-platform
*Subject:* KeyboardEvent question for docs update

> I also found that this was the best (in the sense of "easiest to find
> using a search engine") resource containing this information when I
> was looking for it recently. If, however, the same information exists
> in other more canonical locations that I was simply unable to locate,
> I wouldn't object to the MDN page simply linking to these resources. 

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

KeyboardEvent question for docs update

[Eric Shepherd]

Currently, our docs for KeyboardEvent.key and KeyboardEvent.code try to
provide direct maps of each major OS's keycodes to the values that
result from pressing them. This makes for lots of tables with a lot of
repetitive information.

I'm looking to simplify this.

How useful is it to have all of these tables, rather than just a list of
the key values (or code values, for KeyboardEvent.code) and what they
mean, and leaving the mapping of the hardware code to the standard
values to OS-level documentation?

I can continue to provide the per-OS information (I'd kind of like to --
but I have to consider the time involved), but if it's only marginally
helpful, it may not be worth the maintenance cost, so I'd like to see if
there are opinions on that.

What I'd like to do is provide tables broken down by key category
(navigation, whitespace, modifier, etc) like the spec does, because I
think that's really handy, with tables that have columns for the key
value, description, and (if useful) a column for each of the major
platforms.

Any thoughts appreciated!


-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Tech review needed for RTCPeerConnection reference

[Eric Shepherd]

I've finished the first part of the RTCPeerConnection documentation, and
could use a technical review of the reference material for it; the
following sections of the WebRTC spec should be covered pretty close to
completely (a couple of support interfaces may not be done yet):

4. Peer to peer connections
6. Peer to peer data API

Parts of section 9 (Identity) are also done or partly done, but I'm not
asking for review on those yet.

If you know WebRTC fairly well, it would be awesome if you can find a
little time to read over the page at
https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection and
its subpages and either fix any mistakes or anything unclear, or email
me to let me know what you find that needs work.

Feel free, too, to tweak or add code sample snippets!

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Doc tech review needed for RTCDataChannel

[Eric Shepherd]

I've finished the first version of the reference documentation for
RTCDataChannel. That material is here:
https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel

I would appreciate it if anyone who knows WebRTC would look over that
page and its subpages (the properties and methods of RTCDataChannel) and
check them over for accuracy.

You can either edit the documents to fix mistakes or clarify things, or
you can jot your suggestions in an email to me. Either way. :)

The docs are meant to follow the specification, then note when browsers'
implementations deviate from the spec.

If you know anything that's missing or wrong in the compatibility
tables, please advise or update on that, too.

Thanks in advance to anyone who has a chance to look over any of this
material!

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

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

[Eric Shepherd]

Do: do you want this method documented or not? I presume not, since
exposure will be limited.


*From:* Chris Pearce
*Sent:* Thursday, Jun 2, 2016 4:40:59 PM EDT
*To:* dev-platform@lists.mozilla.org
*Subject:* Intent to implement: HTMLMediaElement::seekToNextFrame()

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

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

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

[Eric Shepherd]

This will be great for writing JavaScript code that applies filters or
effects to video, too. Sweet.


> *Summary*: HTMLMediaElement::seekToNextFrame() is an experimental feature
> which enables JS developers to access video frames one-by-one without going
> through the real-time playback. Internally, this feature could could be
> used to writ media tests.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

How badly out of date is this?

[Eric Shepherd]

Found myself looking at this page today, which is now labeled as
potentially obsolete due to not having undergone any substantial changes
in many years. Could someone please look it over and let me know if it's
worth keeping or salvageable at least?

https://developer.mozilla.org/en-US/docs/Modularization_Techniques

If it's worth keeping, I'll move it to the Mozilla documentation area.
If not, the archival area.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Eric Shepherd]

That's what I figured, but the articles about it didn't seem to say, and
the late hour caused me not to think to look at the spec itself. Good deal.


> That's a no-op per https://dom.spec.whatwg.org/#dom-event-preventdefault.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Eric Shepherd]

What happens if the developer specifies passive yet calls
preventDefault() anyway?


*From:* Kartikaya Gupta
*Sent:* Wednesday, May 4, 2016 6:19:20 PM EDT
*To:* dev-platform
*Cc:* Rick Byers
*Subject:* Intent to implement and ship: "passive" option for
AddEventListenerOptions

> Summary: Authors can declare in their addEventListener call that the
> listener will not be calling preventDefault() on the event. This
> unlocks certain performance optimizations.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: One Firefox repository to rule them all

[Eric Shepherd]

For what it's worth it would be an absolute game changer for the
developer docs team. I already commented that having the unified repo is
a big deal, but having it go all the way to the beginning would rock our
worlds.

Having to wade through by hand and basically do a manual binary search
to figure out which release a change took place in can take a lot of our
time. If we could get this all in one place -- holy cow, I would be
bursting with happy sparkly rainbow kittens!


> No. Adding a Mercurial repo with CVS history isn't on the priority
> list. Make a case for it improving developer productivity and it could
> be. 

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: One Firefox repository to rule them all

[Eric Shepherd]

Yes, this is how I feel too, but anything that gets all revisions in one
place would be a huge win for us.


> For me, having the CVS history in the mozilla-central repo

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: One Firefox repository to rule them all

[Eric Shepherd]

This has potential to be a Huge Deal for the MDN content team, too.
Figuring out when things were added or removed or changed can be hard
across so many repositories.


> I'm pleased to announce the immediate availability of some
> *experimental* read-only Mercurial repositories containing the
> combined, useful history of the various Firefox repositories, all in
> chronological order and stored in a more efficient format that is
> faster to clone and pull from and results in faster client operations.
>
> The repositories can be found at https://hg.mozilla.org/experimental.
> The repository you likely want to clone is
> https://hg.mozilla.org/experimental/firefox-unified. A visualization
> showing the chronological history of the repo can be seen at
> https://hg.mozilla.org/experimental/firefox-unified/graph.
>
> The primary goal of these repositories is to provide developers (and
> eventually automation) with more efficient interaction with the
> Firefox source repositories. There are several secondary and
> side-benefits, including improving the scalability of Try and
> MozReview's repositories.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: Intent to unship support for altGlyph

[Eric Shepherd]

Added dev-doc-needed.


*From:* longs...@gmail.com
*Sent:* Friday, Apr 29, 2016 1:40:00 PM EDT
*To:* dev-platform@lists.mozilla.org
*Subject:* Intent to unship support for altGlyph

> We have had minimal support for altGlyph for some time now as an alias for 
> tspan. altGlyph has been dropped from SVG 2 and neither Chrome nor Edge 
> support the  ->  fallback behaviour, though Safari still 
> does.
>
> The patch to remove it from the tree is available at [1].

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: Clarifications needed to 'Intent to ship' process

[Eric Shepherd]

I'd also love to take this opportunity to remind everyone, especially
our newer contributors and developers, to be sure to add the
"dev-doc-needed" keyword to the appropriate bugs for any changes which
should include updates to documentation on MDN.

See
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Getting_documentation_updated
for details on how this system works to help us document all the good stuff.


*From:* smaug
*Sent:* Monday, Apr 25, 2016 1:19:16 AM EDT
*To:* dev-platform@lists.mozilla.org
*Subject:* Clarifications needed to 'Intent to ship' process

> based on couple of conversations we need some clarifications to
> 'intent to ship'.
>
> First, we aren't yet consistent enough to send 'intent to ship'
> emails. I think that takes
> just some time for patch authors and reviewers to get used to the
> process, that whenever there is some
> larger than minor web phasing API addition/removal being done, 'intent
> to ship' email to this list should be sent.
>
> Second, it isn't clear how we're supposed to react to the 'intent to
> ship' emails.
> I propose we require two OKs from the owners/peers of the relevant
> module (of which one could be given while reviewing the patch), and
> definitely no opposing comments from the owners/peers. But in case
> other people object... I guess we'll always have special cases and
> process can be
> improved when needed.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: Triage Plan for Firefox Components

[Eric Shepherd]

This also has the effect of being somewhat confusing for the docs team,
since we may use your priority labels when planning the order in which
to work. Having a standardized system would make our lives easier and
improve the quantity and quality of the material we produce to document
y'all's work.

> I think we need to have a uniform way of identifying bugs that matter to a
> release. Having a different mechanism for each team means that we're likely
> to miss something.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: Intent to ship: Support for color-adjust CSS property

[Eric Shepherd]

A note from the developer docs team: when you do this, please be sure
that you both share the information about the existence of the
preference to the bug about adding the feature -- and be sure to add
dev-doc-needed to the bug for removing the preference. If there's not a
bug for some reason, please file a bug against the developer
documentation telling us the preference and the feature it controls, so
we can properly document its removal for developers.

The best way to do this is to include in the Bugzilla comment when you
add dev-doc-needed a note about the name of the preference and that it's
been added or removed. But anywhere that it stands out to the writers
when we look at the bug is helpful.

Thanks in advance for your help!

(This is of course great general advice whenever a feature is introduced
behind a pref, btw).


*From:* Lawrence Mandel
*Sent:* Friday, Mar 4, 2016 10:15:12 AM EST
*To:* Tobias Schneider
*Cc:* dev-platform
*Subject:* Intent to ship: Support for color-adjust CSS property

> Whether or not we ship with the feature enabled, the ability to disable a
> feature with a pref gives us an easy out if a critical issue is discovered.
> (For ex, a code path that results in a top crash.) I suggest that we create
> the pref in either case and plan to remove it after a couple of releases if
> no critical bugs have come in.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Web API / developer docs / dev. evangelism meeting Thursday at 8 AM PST

[Eric Shepherd]

The Web API documentation community meeting, with representatives from 
the technical evangelism and the API development teams, will take place 
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your 
time zone).


Typical meetings include news about recent API development progress and 
future development plans, discussions about what the priorities for 
documenting and promoting new Web technologies should be, and the status 
of ongoing work to document and evangelize these technologies.


We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2016-02-04.

If you have topics you wish to discuss, please feel free to add them to 
the agenda.


We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to 
the agenda. Also, if you're unable to attend but have information or 
suggestions related to APIs on the Web, their documentation, and how we 
promote these APIs, please add a note or item to the agenda so we can be 
sure to address it, even if you're unable to attend.


--

Eric Shepherd
Senior Technical Writer
http://developer.mozilla.org
http://bitstampede.com
http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

NO Web APIs documentation/dev/evangelism meeting this week

[Eric Shepherd]

Our regular Thursday morning meeting will not take place this week due
to the holiday weekend many of our folks are enjoying. Whether you
celebrate or not, please have a safe and happy weekend and we'll see you
next week!
-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/evangelism/dev team meeting Thursday at 8 AM PST

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-12-17.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/evangelism meeting Thursday at 8 AM PST

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-12-03.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/evangelism/dev team meeting Thursday at 8 AM PST

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-11-26.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Web APIs documentation/evangelism/dev team meeting Thursday at 8 AM PST

[Eric Shepherd]

> Eric Shepherd <mailto:esheph...@mozilla.com>
> November 25, 2015 at 8:14 AM
> The Web API documentation community meeting, with representatives from
> the technical evangelism and the API development teams, will take
> place on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for
> your time zone).
>
> Typical meetings include news about recent API development progress
> and future development plans, discussions about what the priorities
> for documenting and promoting new Web technologies should be, and the
> status of ongoing work to document and evangelize these technologies.
>
> We have an agenda, as well as details on how to join, here:
>
> https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-11-26.
>
> If you have topics you wish to discuss, please feel free to add them
> to the agenda.
>
> We look forward to seeing you there!
>
> If you have topics you wish to discuss, please feel free to add them
> to the agenda. Also, if you're unable to attend but have information
> or suggestions related to APIs on the Web, their documentation, and
> how we promote these APIs, please add a note or item to the agenda so
> we can be sure to address it, even if you're unable to attend.
>
> 
My finger hadn't even finished lifting off the "send" button when I
remembered that this meeting is canceled this week due to the United
States's Thanksgiving holiday. Please ignore this notice.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/dev/evangelism meeting Thursday at 8 AM PST

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-11-19.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

API documentation/evangelism/dev teams meeting Thursday at 8 AM PST

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-11-12.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/development/engagement meeting Thursday at 8 AM PST

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-11-05.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/evangelism/engineering teams meetup Friday at 8 AM PST

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-10-22.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Web APIs documentation/evangelism/engineering teams meetup Friday at 8 AM PST

[Eric Shepherd]

> Eric Shepherd <mailto:esheph...@mozilla.com>
> October 20, 2015 at 1:54 PM
> The Web API documentation community meeting, with representatives from
> the technical evangelism and the API development teams, will take
> place on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for
> your time zone).
>
> Typical meetings include news about recent API development progress
> and future development plans, discussions about what the priorities
> for documenting and promoting new Web technologies should be, and the
> status of ongoing work to document and evangelize these technologies.
>
> We have an agenda, as well as details on how to join, here:
>
> https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-10-22.
>
> If you have topics you wish to discuss, please feel free to add them
> to the agenda.
>
> We look forward to seeing you there!
>
> If you have topics you wish to discuss, please feel free to add them
> to the agenda. Also, if you're unable to attend but have information
> or suggestions related to APIs on the Web, their documentation, and
> how we promote these APIs, please add a note or item to the agenda so
> we can be sure to address it, even if you're unable to attend.
>
> 
Oops! This is on THURSDAY, not Friday. Sorry about that! Thursday at 8
AM PST.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New agenda URL for tomorrow's 8 AM PDT API docs/evangelism/dev team meeting

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-10-08.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/evangelism/dev team meeting

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-10-08.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web API docs/evangelism/dev team meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-10-01.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/evangelism/dev meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-09-24.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.


-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Directory picking and directory drag-and-drop

[Eric Shepherd]

Eric Rescorla wrote:
> I think there are some fairly obvious issues here, including:
>
> - There are obvious sensitive files you shouldn't upload under
>   basically any conditions.
> - It's hard for the client to know what the implications of any directory
> upload are
>   because they may not know what's in a given directory.
I'm not a big fan of "the user is stupid and we have to protect him" as
an argument. :)

There are a lot of genuinely valid use cases for this feature; yes,
security concerns should definitely be considered, but it's important to
be clear that if you want to address security concerns, or kill off the
feature entirely. I hope it's the former, because the number of times
this exact thing has come up for me is not easy to dig up, since it's
been a lot of times, especially when working on web deployments or
staging of assets for media services.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Directory picking and directory drag-and-drop

[Eric Shepherd]

Jonas Sicking wrote:
> Note that this, similarly to clipboard integration, is already exposed
> to the web through flash. So the main goal of this feature is to
> enable developers to migrate off of flash and instead use Gecko.
>
> That said, if there are ways we can improve the UI here to further
> explain to users what is going on, then that sounds good to me.
My concern with shipping this would be that it seems very far removed
from being a proper proposed spec at this point. Seems to just be an
unofficial draft. Shouldn't it spend more time preffed off to give
developers more time to offer feedback? It's only been a few weeks since
this was first brought up, and we've not exactly made it broadly known
that it could use some trying-out.

I like the idea in general though; having no way to do this has been a
long-standing problem when trying to build file server managers, sharing
services, and the like.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/evangelism/dev team meetup Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-09-17.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/engagement/dev team meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-09-03.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.


-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/esheph...@mozilla.com>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/engagement/developer meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-08-27.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability https://freebusy.io/esheph...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs docs/tech evangelism/dev team meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-08-20.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability https://freebusy.io/esheph...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we make a plan to retire Universal Mac builds?

[Eric Shepherd]

Hubert Figuière wrote:
 But Only 10.7 and later can NOT run on 32-bits hardware. Which mean that
 unless we require 10.7, there is still a possibility the users run a
 machine that is not 64-bits capable, hence not able to run a 64-bits
 build of Firefox.
Yes, this is the point here -- some percentage of those Snow Leopard
(10.6) users are probably on 32-bit hardware. Is there a way to tell how
many? If we can't tell, is there a way to add some flag to telemetry
data that would provide this info, so we can make an informed decision?

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability https://freebusy.io/esheph...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we make a plan to retire Universal Mac builds?

[Eric Shepherd]

Gregory Szorc wrote:
 These are the blockers that I recall as well. However, I /think/ we've 
 already decided that  #1 is no longer a hard blocker and we can proceed as 
 soon as #2 is resolved. Dropping universal Mac builds can't come soon enough 
 given the impact to build system complexity and overhead in automation.
While I'm never happy to leave old stuff behind, I agree that this makes
sense. When that decision is made, it may be worth making a call-out to
the community to (a) let them know well in advance, and (b) offer the
opportunity for volunteers to start their own project to maintain a
32-bit Intel build if they really want it (similar to the TenFourFox
project).


-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability https://freebusy.io/esheph...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

API docs/development/evangelism team meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from the 
technical evangelism and the API development teams, will take place on Thursday 
at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your time zone).

Typical meetings include news about recent API development progress and future 
development plans, discussions about what the priorities for documenting and 
promoting new Web technologies should be, and the status of ongoing work to 
document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-08-06.

If you have topics you wish to discuss, please feel free to add them to the 
agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to the 
agenda. Also, if you're unable to attend but have information or suggestions 
related to APIs on the Web, their documentation, and how we promote these APIs, 
please add a note or item to the agenda so we can be sure to address it, even 
if you're unable to attend.


Eric Shepherd
Senior Technical Writer
Mozilla Developer Network https://developer.mozilla.org/
Blog: http://www.bitstampede.com/
 http://www.bitstampede.com/Twitter: http://twitter.com/sheppy 
http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XULRunner future and ownership

[Eric Shepherd]

 reverendli...@gmail.com mailto:reverendli...@gmail.com
 July 30, 2015 at 10:17 AM

 I'll volunteer to help out with documentation.
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 Benjamin Smedberg mailto:benja...@smedbergs.us
 July 29, 2015 at 2:30 PM
 The Mozilla project no longer sees XULRunner as a priority project.
 It's not core to advancing the open web or any of our current or
 planned products.

 As Ben Hearsum noted a couple weeks ago, we are turning off automated
 XULRunner builds and so XULRunner will probably quickly cease to work.
 In order to keep XULRunner in the tree, we need an owner who wants to
 keep it building and running properly. Currently, I am the nominal
 owner of the XULRunner code, but I have no desire to do this work or
 even really to review the necessary patches. I am looking to see
 whether there is an alternate owner who is interested in the task of
 keeping XULRunner building and running properly and reviewing patches
 to XULRuner-specific code. Please contact me if you want to nominate
 yourself or somebody else for this role.

 If I do not find a suitable owner in the next two weeks, I intend to
 remove the XULRunner code from the mozilla-central repository on
 14-August.

 --BDS

 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 
Awesome! Hopefully you'll be able to have no serious trouble keeping up
the XULRunner docs. Please do have a look at our content and style
guide: https://developer.mozilla.org/en-US/docs/MDN/Contribute/Content

And if you or anyone else helping with XULRunner docs needs help getting
going with editing on MDN, our starter guide is here:
https://developer.mozilla.org/en-US/docs/MDN/Getting_started

Please feel free to ping me any time by email or on IRC if you'd like to
talk about it. I've been at this stuff for a long time so I may have
useful advice to offer if you need it.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability https://freebusy.io/esheph...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XULRunner future and ownership

[Eric Shepherd]

Benjamin Smedberg wrote:
 I am looking to see whether there is an alternate owner who is
 interested in the task of keeping XULRunner building and running
 properly and reviewing patches to XULRuner-specific code. Please
 contact me if you want to nominate yourself or somebody else for this
 role. 
I should note also that the MDN staff can't put any time into helping
with XULRunner specific documentation anymore, so any documentation work
would have to be taken up by the person or people that pick up the project.

I would, however, be quite happy to spend some time helping whoever
takes on that work -- or whoever picks up writing work for it -- on
exactly how to contribute the needed material to MDN.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability https://freebusy.io/esheph...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

API docs/evangelism/development teams meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-07-30.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability https://freebusy.io/esheph...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

API docs/evangelism/development teams meeting Thursday at 8 AM PDT

[Eric Shepherd (Sheppy)]

The Web API documentation community meeting, with representatives from the
technical evangelism and the API development teams, will take place on
Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your time
zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status of
ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-07-23.

If you have topics you wish to discuss, please feel free to add them to the
agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to the
agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Collecting web platform features implementation status

[Eric Shepherd]

Agreed. This is about how we feel about a spec, its content, and the design of 
its API, not about if or when we will get around to implementing it. That's 
also something worth capturing, but they're not the same data points at all.

Eric Shepherd
Sr. Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy

 On Jul 16, 2015, at 10:26 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
 
 Thinking about this more, I really don't see why we should try to narrow down 
 the list to fewer items.  I feel like our default position on a random spec 
 is no opinion, because we aren't aware of the content
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

API documentation/evangelism/development teams meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-07-16.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability https://freebusy.io/esheph...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Busy indicator API

[Eric Shepherd]

Jonas Sicking wrote:
 window.navigator.addBusyTask(promise);

 would be great. The API can be called any time and any number of
 times. The API would run the spinner until all provided promises are
 resolved. So if it's called twice with different promises, the spinner
 doesn't stop when one of the promises are resolved, but rather when
 the last promise is resolved.
I love this idea. It makes it possible for lots of apps to start a busy
indicator, but in reality, they're all sharing one spinner up at the top
of the screen, and that spinner keeps running until all promises are
resolved, at which point it goes away.

This is similar to how iOS does things, from a visual perspective.
There's one spinner indicator that appears in the status bar at the top
of the screen when any software is actively using the network. But this
API suggestion is a really elegant idea for implementing it.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web API documentation and evangelism meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-07-09.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Eric Shepherd]

 Karl Tomlinson mailto:mozn...@karlt.net
 July 7, 2015 at 12:55 AM

 I find the 'a' prefix useful to tell me that this variable has the
 value that was provided to the function.
 (I'm assuming that the prefix is used with this convention.)

 There's no additional safety enforced, but I find the single
 letter helps readability.

 For example, if I want to know where the value of a variable comes
 from, and it starts with 'a', then I know immediately that I can
 skip looking at that particular function in the call chain/graph
 and I need to look at the calling function(s).

 That advantage does not exist in a declaration that is not a
 definition; this is only helpful in the definition.
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 
FWIW, as a tech writer that has to take all this stuff and make sense of
it in documentation, I dislike aFoo but I'm fine with mFood and such
to differentiate methods from properties from constants, etc.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

API Documentation and Tech Evangelism meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-07-02.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [feature] open certain domains into a private window

[Eric Shepherd]

I thought we had an open in new private window option when right clicking 
links. Not a total solution but helps.

Eric Shepherd
Sent from my iPhone

 On Jun 23, 2015, at 6:00 PM, Karl Dubost kdub...@mozilla.com wrote:
 
 Margaret,
 Let's hope it's the appropriate list (or maybe I should just open a bug about 
 it).
 
 For privacy reasons, I would love to have certain domain names (and/or links) 
 opened in specific silos. 
 
 Use case:
 I'm reading an email with a link to Google Doc.
 As a user I want all Google Docs links opened automatically in a private 
 window. I can save this preference in a list of domain names where I would 
 love the same behavior. 
 
 
 Currently:
 1. I need to copy the link
 2. open a new private window
 3. paste the link
 
 
 I guess in the consequences for the platform, the link needs to be caught 
 very early on before any HTTP requests are done. 
 
 PS: An additional feature, A private window with privileged access to certain 
 parameters such as login/password which are saved from session to session but 
 only for this specific domain. 
 
 -- 
 Karl Dubost, Mozilla
 http://www.la-grange.net/karl/moz
 
 ___
 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: Voting in BMO

[Eric Shepherd (Sheppy)]

On Tue, Jun 9, 2015 at 5:09 PM, Mark Côté mc...@mozilla.com wrote:

 To that end, I'd like to consider the voting feature.  While it is
 enabled on a quite a few products, anecdotally I have heard
 many times that it isn't actually useful, that is, votes aren't really
 being used to prioritize features  fixes.  If your team uses voting,
 I'd like to talk about your use case and see if, in general, it makes
 sense to continue to support this feature.


​We used voting for a while on the MDN platform project, but the process
changed a year or so ago and they're not actively being used anymore, I
think.​

​I found it to be a pretty neat feature, frankly. I use it for personal
projects on my own Bugzilla for shareware stuff I do for retro machines.​


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Replacing Mozmill driven tests for Firefox with Marionette

[Eric Shepherd]

Henrik Skupin wrote:

All the above should give you a quick overview and understanding what's
going on with Mozmill and Marionette. For the individual topics I might
follow-up with separate blog posts and a more detailed description of
work happening in those areas.
Quick note: This obviously impacts the building/developing Mozilla 
documentation, which has quite a bit of coverage of Mozmill and how to 
use it for testing Firefox etc. If you can share any details, notes, etc 
that would be relevant, I would appreciate it.


--

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd (Sheppy)]

On Thu, May 7, 2015 at 12:43 AM, Adam Roach aro...@mozilla.com wrote:

 Which leaves us with a conundrum regarding your plea for more notice:
 it's a bit hard to seriously consider complaints that at some future
 date yet to be determined is too soon.


​My apologies. My reading of the announcements indicated that this was
happening in Firefox 40, which is very soon. It was not at all clear that
there was some kind of step by step process (indeed, this message was the
first time I picked up on that, despite reading this thread fairly closely
-- perhaps communications being clearer would have helped).

I suspect a lot of this kerfuffle could have been dodged had the original
posting been a little more thorough and more cautiously worded.​ Trying to
tease these nuances out of a long and emotional thread has been difficult,
unfortunately.

It was not clear until quite a few messages into the thread that this
wasn't all happening at once, and wasn't automatically being applied to all
servers. It sounded very much as if all unencrypted HTTP was going to be
rejected starting in Firefox 40. Now that I know that's not the case, I'm
much less concerned, although not 100% living in happy unicorns and
rainbows land.



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

[Eric Shepherd (Sheppy)]

A request from the docs team: once the final decisions are made, please
either let us know what those decisions are (use our doc request form:
https://bugzilla.mozilla.org/form.doc) or update the coding style guide
yourselves (
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style).
Either one wins you brownie points, but updating the doc yourselves will
result in super-tasty brownie points.

On Thu, May 7, 2015 at 9:52 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:

 On 2015-05-05 2:51 PM, Jeff Walden wrote:

 Seeing this a touch late, commenting on things not noted yet.

 On 04/27/2015 12:48 PM, Ehsan Akhgari wrote:

 I think we should change it to require the usage of exactly one of these
 keywords per *overridden* function: virtual, override, and final.  Here
 are the advantages:

 * It is a more succinct, as |virtual void foo() override;| doesn't convey
 more information than |void foo() override;|.
 * It makes it easier to determine what kind of function you are looking
 at
 by just looking at its declaration.  |virtual void foo();| means a
 virtual
 function that is not overridden, |void foo() override;| means an
 overridden
 virtual function, and |void foo() final;| means an overridden virtual
 function that cannot be further overridden.


 All else equal, shorter is better.  But this concision hurts readability,
 even past the non-obvious final/override = virtual implication others have
 noted.  (And yes, C++ can/should permit final/override on non-virtuals.
 JSString and subclasses would be immediate users.)


 At the risk of repeating myself and others here, let's not worry about
 what C++ should do if it were being redesigned today, and let's focus on
 what it actually does.

  Requiring removal of virtual from the signature for final/override
 prevents simply examining a declaration's start to determine whether the
 function is virtual.  You must read the entire declaration to know: a
 problem because final/override can blend in.  For longer (especially
 multiline) declarations this matters.  Consider these SpiderMonkey
 declarations:

   /* Standard internal methods. */
  virtual bool getOwnPropertyDescriptor(JSContext* cx, HandleObject
 proxy, HandleId id,

  MutableHandleJSPropertyDescriptor desc) const override;
  virtual bool defineProperty(JSContext* cx, HandleObject proxy,
 HandleId id,
  HandleJSPropertyDescriptor desc,
  ObjectOpResult result) const override;
  virtual bool ownPropertyKeys(JSContext* cx, HandleObject proxy,
   AutoIdVector props) const override;
  virtual bool delete_(JSContext* cx, HandleObject proxy, HandleId id,
   ObjectOpResult result) const override;


 virtual is extraordinarily clear in starting each declaration.
 override and final alone would be obscured at the end of a long string
 of text, especially when skimming.  (I disagree with assuming syntax
 coloring penalizing non-IDE users.)


 This is basically what Trevor was arguing for.  I don't think there is
 much more to say on this as we're basically comparing what you and I are
 used to read.

  * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead.


 A better alternative, that exposes standard C++ and macro-hides
 non-standard gunk, would be to use NS_IMETHOD for everything and directly
 use |virtual| in declarations.  This point is no justification for changing
 style rules.


 That has similar verbosity issues.  But yeah I agree on the broader point
 that this macro situation can be solved in other ways, we just disagree
 what those ways should be.  :-)

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




-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd]

Gervase Markham wrote:

For this edge case, I would say the solution is to use a proxy, run on
one of your other (faster) computers. As noted elsewhere, that's what
jwz did to get Netscape 1.0 (which only spoke HTTP 1.0) working again.
That's a reasonable solution for one-offs, but not really viable if you 
have a bunch of hobbyists who don't necessarily have the technical 
background to deal with that. Even I don't know how to set up a proxy 
like that. I'm sure it wouldn't take me long to learn, but I certainly 
can't expect all the people who use programs I write to know how to do it.


I get, of course, that this is the way of progress. Just... would have 
been nice to have more notice, since we're going to have to try to find 
someone to build, produce, and market a simple, plug-and-play mechanism 
to handle encryption and decryption of data in order to keep these hobby 
machines online over the long term.


Will make for a fun project for someone, but will take time.

--

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: No more binary components in extensions

[Eric Shepherd]

Benjamin Smedberg wrote:
I will be updating MDN documentation and removing or archiving old 
documentation about binary XPCOM components in the next few weeks. 
Please ping me before outright deleting anything; I'd like to be sure 
we're able to continue to support people embedding Gecko or targeting 
projects other than Firefox. Thanks!


--

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd]

Richard Barnes wrote:
Nobody right in the head is going to be plugging an antique with a 
1mhz processor directly into an unfiltered, internet-facing network 
connection, but I guess people who aren't right in the head like that 
are still people whose concerns deserve consideration. 
The SE/30 was 16 MHz, but it was also 32-bit, which makes a lot of 
difference as compared to an 8 or 16 bit machine when trying to do 
modern crypto. And I promise not to talk about retro gadgets anymore, 
since this is way off topic.


FWIW, I concede that I'm among those that misinterpreted the original 
email on this. That it's still going to be possible to do basic things 
is good to know.


I admit I'm a mite sensitive about the issue, because our little 
community of retro hackers has been working for a very long time (over 
twenty years now!) on bringing up TCP/IP stacks, getting newer and 
better network adapters designed and built, drivers written and 
optimized, etc. We finally get to the point where cool stuff is starting 
to really be feasible and this comes along. It was a little like driving 
your sled dog team through the worst blizzard in history to be the first 
person to the North Pole only to have someone steal your sled just 
before you get there. :)


--

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd]

Martin Thomson wrote:

There are two aspects to this: the software, and the content.

If software cannot be updated, that a problem in its own right.  The
idea that you could release your server onto the Internet to fend for
itself for 20 years was a dream of the 90s that has taken a while to
die.  Just as you have to feed it electricity and packets, you have to
maintain software too.
In my case, the situation is that I have classic computers running 1-10 
megahertz processors, for which encrypting and decrypting SSL is not a 
plausible option. These computers have a burgeoning retro fanbase 
trying to push them to do new and interesting things, and a lot of that 
involves writing software that works over the Web using standard 
protocols. These efforts cannot be sustained in an HTTPS-only world.


This has personal meaning to me as a long-time member of the 
retrocomputing community, and as the author of software that runs on 
these machines, including multiple programs that use HTTP to do so. If 
things start requiring HTTPS, our ability to continue to innovate and 
try to push these machines to do more and more things previously unheard 
of starts to come to an end. I don't like that notion very much.


Is it a niche case? Sure. But it's not one to be dismissed outright 
without at least having its voice heard, so here I am, representing our 
little crowd.


I'm not trying to stir up trouble or be a pain in the ass. Just pointing 
out that there honestly, truly are valid use cases for straight-up HTTP, 
even if they're rare.


(FWIW, I concede that the not everything needs encryption position is 
a little overstated, but I also think that there really is stuff that 
doesn't need encrypting, even if it's a tiny fraction of the Web's traffic).


--

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing cruft preferences

[Eric Shepherd]

Boris Zbarsky wrote:
I'd appreciate it if people would go through their IDL, find the 
things that are still cruft, and remove them... 
The docs team would appreciate a heads-up for any that get removed 
(either by email or by dev-doc-needed if you use bugs to track the 
work). Even for prefs that are probably uninteresting, we should note 
their removal in the appropriate Firefox X for developers pages.


--

Eric Shepherd
Senior Technical Writer
Mozilla https://www.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform