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

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

> On Sun, Mar 18, 2018 at 5:27 PM Patrick McManus 
> 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 
___
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 
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 
___
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 
Blog: https://www.bitstampede.com/
Twitter: https://twitter.com/sheppy

> On May 11, 2017, at 11:32 PM, Bill McCloskey  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 
Blog: https://www.bitstampede.com/
Twitter: https://twitter.com/sheppy

> On May 11, 2017, at 1:40 PM, Andreas Farre  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

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: 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: 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: Is MOZ_SHARK still used?

[Eric Shepherd (Sheppy)]

Is it worth talking to someone from the TenFourFox project
(http://www.floodgap.com/software/tenfourfox/)  to see if they have an
opinion on this? They may be using Shark still for their debugging and
testing processes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation meeting Friday at 10 AM PDT

[Eric Shepherd (Sheppy)]

The Web APIs documentation meeting is Friday at 10 AM Pacific Time
(see http://bit.ly/APIdocsMDN for your time zone). Everyone's welcome
to attend; if you're interested in ensuring that all Web APIs are
properly documented, we'd love your input.

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

https://etherpad.mozilla.org/WebAPI-docs-2015-04-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 been working
on documentation related to APIs, please add notes to the agenda about
what you've been doing so we can share your progress.

-- 

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: [meta] Intent to implement - captured some docs on wikimo

[Eric Shepherd (Sheppy)]

Should we add documentation for this to the Developer Guide on MDN? We
cover a lot of the development process there, so it may be wise to
include this information there, unless someone can think of a good
reason not to.

On Tue, Mar 31, 2015 at 9:08 PM, Jonas Sicking jo...@sicking.cc wrote:
 Ah, sorry, I misunderstood the intent of the wiki page. I retract my concern.

 / Jonas

 On Wed, Apr 1, 2015 at 12:41 AM, Tantek Çelik tan...@cs.stanford.edu wrote:
 Having pages go out of date can certainly be a challenge, hence why
 this wiki page is descriptive (citing historical examples and other
 external resources), rather than prescriptive.

 No additional risk of becoming out of date beyond that from already
 existing pages. It's a general good practice to write wiki-pages in
 such a future-defensive way.

 I'll also add a note about any questions about intent to ... should
 go to dev-platform to provide direction should anything actually go
 out of date and someone is potentially confused.

 Thanks,

 Tantek

 On Tue, Mar 31, 2015 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote:
 Will someone be maintaining this page? I'm worried that having an
 out-of-date page might create more confusion than information.

 / Jonas

 On Tue, Mar 31, 2015 at 3:58 AM, Tantek Çelik tan...@cs.stanford.edu 
 wrote:
 Having followed the Intent to implement emails for a while, and
 noticing that there was already an email template for it on wikimo:

 https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement


 I went ahead and wrote up a page about this practice, along with links
 to Blink/MS equivalents:

 https://wiki.mozilla.org/Intent_to_implement

 Hopefully others find this useful.

 Feedback and as usual, direct edits/contribution to the page welcome
 and encouraged.

 Thanks,

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



-- 

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: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|

[Eric Shepherd (Sheppy)]

Is the bug tasking this marked dev-doc-needed? We will have SD

A bunch of cleanup to do

On Thursday, March 26, 2015, Jan De Mooij jdemo...@mozilla.com wrote:

 Hi all,

 After some discussion, we want to switch SpiderMonkey and XPConnect style
 for pointers/references from |T *p| to |T* p| (and |T ref| to |T ref|).
 This matches the rest of the project and will make life easier for
 developers working on multiple parts of the tree.

 Although this will break a lot of patches, you can run the script in bug
 1144366 [0] on patch files too and they should apply cleanly after that
 (make sure you have backups):

 restyle.py --files patch1 [patch2..]

 The plan is to land this change next weekend or early next week. We'll
 likely land this on aurora/beta/ESR as well, to avoid painful uplifts.

 Finally, a common argument for the current style is that it might be
 clearer when you declare multiple pointers, like this:

 int *x, *y;   // x and y are int*

 However, I think this is pretty confusing either way, and both our style
 guide [1] and Stroustrup [2] suggest sticking to one pointer per
 declaration. I'll write a separate patch to do this.

 I'm very sorry for the rebase and merge pain, but we think this is worth
 doing.

 Thanks,
 Jan

 [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1144366
 [1]

 https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Declarations
 [2] http://www.stroustrup.com/bs_faq2.html#whitespace
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org javascript:;
 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

Web APIs documentation meeting Friday

[Eric Shepherd (Sheppy)]

Once again, we'll be holding our weekly Web APIs documentation meeting this
upcoming Friday, January 30. The meeting begins at 10 AM PST and rarely
lasts longer than 15-20 minutes. See http://bit.ly/APIdocsMDN to convert
this time into your time zone.

We welcome and encourage anyone interested in Web APIs to attend; the
mission of this project is to create documentation for all APIs that are
exposed to Web content, so if you work on those APIs or just have an
interest in seeing that they're properly documented, please join us!

We have an agenda, as well as details on how to join, available on this
etherpad:

https://etherpad.mozilla.org/WebAPI-docs-2015-01-30.

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 been working on
documentation related to APIs, please add notes to the agenda about what
you've been doing so we can share your progress.

https://etherpad.mozilla.org/WebAPI-docs-2015-01-30

-- 

Eric Shepherd
Sr. 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

Web APIs documentation meeting Friday at 10 AM PST

[Eric Shepherd (Sheppy)]

The Web APIs documentation meeting is Friday at 10 AM Pacific Time (see
http://bit.ly/APIdocsMDN for your time zone). Everyone's welcome to attend;
if you're interested in ensuring that all Web APIs are properly documented,
we'd love your input.

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

https://etherpad.mozilla.org/WebAPI-docs-2015-01-23

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 been working on
documentation related to APIs, please add notes to the agenda about what
you've been doing so we can share your progress.

We look forward to seeing you there!

-- 

Eric Shepherd
​Sr. 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