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

[Christopher Mills]

No. I didn't even know about that page ;-|

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network <https://developer.mozilla.org/en-US/>
@chrisdavidmills <https://twitter.com/chrisdavidmills>


On Tue, Oct 1, 2019 at 4:39 PM Eric Shepherd (Sheppy) 
wrote:

> 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

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

[Christopher Mills]

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

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network 
@chrisdavidmills 


On Fri, Sep 27, 2019 at 8:10 PM Boris Zbarsky  wrote:

> Starting today (on autoland,coming to m-c soon), there is no more
> [PrimaryGlobal] extended attribute on interfaces in our Web IDL, and
> therefore all interfaces need an explicit [Exposed] annotation saying
> where they are exposed (e.g. [Exposed=Window] for the case that used to
> not have any annotation and default-exposed on mainthread).
>
> This aligns with upstream spec changes.
>
> If someone forgets to add [Exposed] on your interface, the parser will
> helpfully complain that there are globals the interface could be exposed
> on, but it's not exposed on any of them.
>
> Just copy/pasting IDL from specs should generally work; I believe most,
> if not all, specs updated to this upstream change a while ago.
>
> -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: Web IDL now uses mixin syntax, not "implements"

[Christopher Mills]

On Wed, Sep 25, 2019 at 6:43 PM Anne van Kesteren  wrote:

> On Wed, Sep 25, 2019 at 7:13 PM Christopher Mills 
> wrote:
> > Updated our WebIDL page to include this new information:
> >
> >
> https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#Mixins
> >
> > Let me know if you'd rather see something different here.
>
> Thanks! I think my main suggestion would be to lead with the new
> syntax as that should soon be more common. We also do expect that
> eventually all specifications are updated. As part of updating syntax
> in the IDL specification downstream dependencies are notified of
> changes (and thanks to Kagami there's now an experiment of doing so in
> automated fashion for the constructor change).
>

OK, done!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Web IDL now uses mixin syntax, not "implements"

[Christopher Mills]

Updated our WebIDL page to include this new information:

https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#Mixins

Let me know if you'd rather see something different here.

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network 
@chrisdavidmills 


On Tue, Sep 24, 2019 at 6:20 PM Boris Zbarsky  wrote:

> The way mixins are done in IDL has changed syntax somewhat.  Instead of
> having a [NoInterfaceObject] interface and an "implements" statement,
> the new setup looks like this:
>
>interface A {};
>
>interface mixin B {
>  void somethingMixedIn();
>}
>
>A includes B;
>
> In-tree IDL has been updated to the new syntax.  Support for the old
> syntax has not been removed yet, but will be as soon as that patch is
> reviewed; please do not add new IDL using "implements".
>
> The new setup is a little less featureful: mixins have no inheritance
> and cannot include other mixins.  They _do_ support partials, so you can
> do:
>
>interface A {};
>interface mixin B {};
>partial interface mixin B {
>  void somethingMixedIn();
>};
>A includes B;
>
> A mixin and its partials have to in the same .webidl file, just like our
> existing rules for interfaces.  This is not enforced yet, but will be
> soon.  Similarly, the "A includes B" statement must be in the same
> .webidl file as the definition of interface A.  This part _is_ enforced.
>
> Mixins have somewhat restricted syntax compared to interfaces (e.g. do
> not allow mixing in constructors, getter/setter operations, iterable
> declarations, etc).  This should not be a problem in practice, and
> certainly wasn't for anything we had in-tree.
>
> -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: Debug builds and WebGL/OpenGL

[Christopher Mills]

OK, thanks for the input. I'll get back to him.

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network <https://developer.mozilla.org/en-US/>
@chrisdavidmills <https://twitter.com/chrisdavidmills>


On Wed, Sep 18, 2019 at 1:44 PM Jeff Muizelaar 
wrote:

> That page is about debugging Firefox's use of OpenGL. I wouldn't
> recommend what it suggests for trying debug WebGL.
>
> -Jeff
>
> On Wed, Sep 18, 2019 at 5:22 AM Christopher Mills 
> wrote:
> >
> > Hi all,
> >
> > We recently got an MDN support query from a reader looking at this page:
> >
> >
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_OpenGL
> >
> > He wants to use a debug build to debug some of his WebGL code, but
> > complained that the link to download debug builds (
> > https://ftp.mozilla.org/pub/firefox/tinderbox-builds/) doesn't have
> > anything newer than 2017 on it.
> >
> > This page looks to be rather old/out-of-date. My question is — are there
> > newer debug builds somewhere else, or a different way of doing this now
> > that we should recommend instead?
> >
> > Thanks,
> >
> > Chris Mills
> > MDN content lead & writers' team manager
> > Mozilla Developer Network <https://developer.mozilla.org/en-US/>
> > @chrisdavidmills <https://twitter.com/chrisdavidmills>
> > ___
> > 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

Debug builds and WebGL/OpenGL

[Christopher Mills]

Hi all,

We recently got an MDN support query from a reader looking at this page:

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

He wants to use a debug build to debug some of his WebGL code, but
complained that the link to download debug builds (
https://ftp.mozilla.org/pub/firefox/tinderbox-builds/) doesn't have
anything newer than 2017 on it.

This page looks to be rather old/out-of-date. My question is — are there
newer debug builds somewhere else, or a different way of doing this now
that we should recommend instead?

Thanks,

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network 
@chrisdavidmills 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Web IDL constructor syntax

[Christopher Mills]

Thanks Boris.

I've updated the MDN WebIDL guide to include a section on the new syntax:

https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#New_constructor_syntax

(and the new Chrome-only syntax you talked about in your other mail:
https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#Available_only_in_system_code
)

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network 
@chrisdavidmills 


On Fri, Sep 13, 2019 at 1:25 AM Boris Zbarsky  wrote:

> As of today, the syntax for Web IDL constructors no longer involves an
> extended attribute on the interface.  There's now something that looks
> more like a method named "constructor" with no explicitly-defined return
> type.
>
> So this:
>
>[Constructor(DOMString str)]
>interface MyInterface {};
>
> is now written like so:
>
>interface MyInterface {
>  constructor(DOMString str);
>};
>
> This means we can now specify extended attributes on the constructor,
> and therefore we no longer assume that all constructors throw.  If yours
> does, you can use [Throws] in the usual way to indicate that:
>
>interface ThrowingConstructor {
>  [Throws] constructor();
>};
>
> It may take some time for specifications to update to the new syntax
> because not all of the tooling is updated yet; see
> https://github.com/heycam/webidl/issues/778 which tracks that.  So in
> the meantime, including new spec IDL that uses constructors may require
> some hand-editing to get it into the new form.
>
> -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

Workers no longer working on file URLs?

[Christopher Mills]

Hi all,

I was just alerted to the fact that workers no longer seem to work when you
try to run them locally via file URLs (I tested the example at
https://github.com/mdn/simple-web-worker locally). This seems to be the the
case in Fx68 onwards, and newer Chromiums.

Can anybody point me to a bug with more details so I can get this
documented?

Thanks!

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network 
@chrisdavidmills 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: hasFeature() method on some SVG elements

[Christopher Mills]

On Sat, May 4, 2019 at 4:07 AM 墨俊凱 / Cameron McCormack 
wrote:

> On Fri, May 3, 2019, at 8:31 PM, Christopher Mills wrote:
>
> On Fri, May 3, 2019 at 3:38 AM Cameron McCormack  wrote:
>
> The hasFeature() method on some SVG elements comes from SVG 1.0 and was
> intended to be used as part of SVG's extension mechanisms.  This function
> never returned anything other than false in browser implementations, and
> was removed in SVG 2.  Chrome no longer supports this, although WebKit
> still does.  I don't anticipate any issue removing this.
>
> The removal is being done in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1133175.
>
>
> The referenced bug references SVGTests.hasExtension; what's the correct
> one?
>
>
> The method is defined on SVGTests, which is a mixin interface implemented
> by some specific SVG element interfaces (like SVGGraphicsElement).
>

Oh, ok, I get it now. Thanks for your help.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: hasFeature() method on some SVG elements

[Christopher Mills]

On Fri, May 3, 2019 at 3:38 AM Cameron McCormack  wrote:

> The hasFeature() method on some SVG elements comes from SVG 1.0 and was
> intended to be used as part of SVG's extension mechanisms.  This function
> never returned anything other than false in browser implementations, and
> was removed in SVG 2.  Chrome no longer supports this, although WebKit
> still does.  I don't anticipate any issue removing this.
>
> The removal is being done in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1133175.
>

The referenced bug references SVGTests.hasExtension; what's the correct
one?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform