Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make [Exposed] mandatory, remove [PrimaryGlobal] #423

Merged
merged 1 commit into from
Dec 6, 2017

Conversation

tobie
Copy link
Collaborator

@tobie tobie commented Aug 23, 2017

Additionally:

  • Annotate all interfaces in examples with [Exposed].
  • Make [Global] allow a single identifier.

Fixes #365.
Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=26425.


Preview | Diff

@tobie tobie requested a review from annevk August 23, 2017 13:59
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty pretty good.

index.bs Outdated
@@ -4684,16 +4739,24 @@ An interface |A| is considered to be a
For example, if author 1 writes:

<pre highlight="webidl">
[Global,Exposed=Window]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be Global=Window, no?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not according to the current spec which says (emphasis mine):

If the [Global] or [PrimaryGlobal] extended attribute is declared with an identifier list argument, then those identifiers are the interface’s global names; otherwise, the interface has a single global name, which is the interface’s identifier.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we require an identifier since omitting it would only benefit the Window case as far as I can tell and it seems better to be explicit for these.

index.bs Outdated
Note: this is always the case for [=namespaces=],
non-[=callback interface|callback=][=interfaces=],
and [=callback interfaces=] which declare [=constants=],
as they must be annotated with the [Exposed] extended attribute.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cannot use a must in a note.

index.bs Outdated
interface Window {
// ...
};

// By using the same identifier Worker for both SharedWorkerGlobalScope
// and DedicatedWorkerGlobalScope, both can be addressed in an [Exposed]
// extended attribute at once.
[Global=Worker]
[Exposed=Window, Global=Worker]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks wrong.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably need the full [Exposed=DedicatedWorker, Global=(Worker,DedicatedWorker)] thing here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the text right above, my understanding is this should work:

        // By using the same identifier Worker for both SharedWorkerGlobalScope
        // and DedicatedWorkerGlobalScope, both can be addressed in an [Exposed]
        // extended attribute at once.
        [Exposed=Worker, Global=Worker]
        interface SharedWorkerGlobalScope : WorkerGlobalScope {
          // ...
        };

        [Exposed=Worker, Global=Worker]
        interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
          // ...
        };

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well that works, but that makes no sense. You don't want to expose the global interface object in multiple globals.

index.bs Outdated
interface SharedWorkerGlobalScope : WorkerGlobalScope {
// ...
};

[Global=Worker]
[Exposed=Window, Global=Worker]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This as well.

index.bs Outdated
[=takes no arguments|take no arguments=]
or [=takes an identifier list|take an identifier list=].
The [{{Global}}] extended attribute must either
[=takes no arguments|take no arguments=],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this variant really.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really have an opinion about this. This was how it was specified before (maybe implicitly, just for PrimaryGlobal).

@annevk
Copy link
Member

annevk commented Aug 23, 2017

Note that this cannot land until the majority of specifications are updated to use [Exposed]. @zcorpan and I made some effort toward that goal, but it's not done. We probably need tooling to start complaining.

@tobie
Copy link
Collaborator Author

tobie commented Aug 23, 2017

We probably need tooling to start complaining.

Filed w3c/respec#1370 and speced/bikeshed#1077.

@tobie tobie requested a review from domenic August 23, 2017 18:26
@tobie
Copy link
Collaborator Author

tobie commented Aug 23, 2017

Pending question here is whether the [Exposed] extended attribute requirement should be relaxed for interfaces annotated with [NoInterfaceObject] (aka mixins).

@domenic
Copy link
Member

domenic commented Aug 23, 2017

I won't have time to review this, sorry.

I don't think [Exposed] should be required for [NoInterfaceObject], or for future mixins.

@tobie tobie removed the request for review from domenic August 25, 2017 07:39
@annevk
Copy link
Member

annevk commented Aug 31, 2017

Personally I wouldn't mind it if we changed this and slowly chased old specifications to comply.

@bzbarsky should probably sign off on that though.

@bzbarsky
Copy link
Collaborator

It seems ok to me. Forcing all interfaces to always have extended attributes is a bit weird (leading to the question of why that required bit is not using dedicated syntax), but the general idea does have the benefit of forcing people to think about where their new API should be available.

Mixins are complicated. Right now, the spec requires that the exposure set of a mixin be a subset of the exposure set of an interface. That's because the exposure set of the mixin is the default exposure set of all the things being mixed in, and it doesn't make much sense to expose members in places where the interface is not exposed. So we may well want to continue requiring an exposure set for mixins; if not, we need to figure out how things should actually behave. In the proposal where mixins are not required to have [Exposed], what is the exposure set of their members, exactly?

For the same reason, we should probably require [Exposed] even for [NoInterfaceObject], again because it affects exposure of the members.

@bzbarsky
Copy link
Collaborator

Oh, and I'm OK with changing specifications slowly. The only issue is all the unmaintained specs we have, but we can live with that...

I can probably get bugs filed on the specs Gecko implements when we update to this PR (because I'll have to fix them all locally anyway to build the browser).

@annevk
Copy link
Member

annevk commented Aug 31, 2017

The idea for mixins would be that you inherit the exposure of all the interface you mix into. And if you some members cannot be mixed into all those places you could restrict them with local overrides.

@bzbarsky
Copy link
Collaborator

OK, does this PR do that? I, like Domenic, do not have time to read the huge diff carefully in the near term, but a quick skim doesn't show it doing that very well. For example, "The exposure set of the interface is the exposure set of the interface that implements it" is nonsense, because "the interface that implements it" is multiple interfaces with possibly-different exposure sets.

And again, there are non-mixin [NoInterfaceObject] interfaces in the platform...

@tobie
Copy link
Collaborator Author

tobie commented Aug 31, 2017

It seems ok to me. Forcing all interfaces to always have extended attributes is a bit weird (leading to the question of why that required bit is not using dedicated syntax), but the general idea does have the benefit of forcing people to think about where their new API should be available.

Yeah, I agree on both counts. What's your suggestion, should we stay with extended attributed or move to dedicated syntax?

For example, "The exposure set of the interface is the exposure set of the interface that implements it" is nonsense, because "the interface that implements it" is multiple interfaces with possibly-different exposure sets.

That phrasing indeed doesn't work. My intent was to say that if [Exposed] was specified on the mixin itself or on one or more of its members, the mixin members would be exposed in the intersection of the identifiers specified in [Exposed] and the exposure set of the interface implementing it. Otherwise, the mixing members would just be exposed in the globals of the exposure set of the interface implementing it.

And again, there are non-mixin [NoInterfaceObject] interfaces in the platform...

Indeed. We made some incorrect assumptions here.

Maybe this will be easier to spec once we have mixins?

@bzbarsky
Copy link
Collaborator

What's your suggestion, should we stay with extended attributed or move to dedicated syntax?

I haven't thought of non-insane dedicated syntax so far, so I'm probably OK staying with extended attributes.

@annevk
Copy link
Member

annevk commented Sep 1, 2017

And again, there are non-mixin [NoInterfaceObject] interfaces in the platform...

Do we have a list? (Created #430 to discuss this.)

I thought that in this PR we basically didn't change the behavior for [NoInterfaceObject] and continued to require using [Exposed] as we did already.

@tobie
Copy link
Collaborator Author

tobie commented Sep 1, 2017

@bzbarsky
Copy link
Collaborator

bzbarsky commented Sep 1, 2017

I thought that in this PR we basically didn't change the behavior for [NoInterfaceObject]

"change" from what? With this PR as it currently stands, interfaces that are [NoInterfaceObject] are not required to list [Exposed], just as before this PR. But the PR gets rid of the concept of PrimaryGlobal and the default exposure set, so the exposure set for members of such interfaces that don't list [Exposed] is no longer defined after this PR in its current form.

@tobie tobie mentioned this pull request Sep 1, 2017
@tabatkins
Copy link
Contributor

I'm not completely clear from reading this: is [Exposed] allowed/required/disallowed on partial namespaces and interfaces?

@tobie
Copy link
Collaborator Author

tobie commented Sep 25, 2017

I'm not completely clear from reading this: is [Exposed] allowed/required/disallowed on partial namespaces and interfaces?

Allowed (it's shorthand for annotating every member).

@annevk
Copy link
Member

annevk commented Sep 27, 2017

Apologies about adding the merge commit to the PR by the way. I somehow missed this had still outstanding issues and thought that was all that was still needed.

I suspect it's easier to wait for mixins and delay this a little bit, though if tooling can start requiring it that would be good of course.

@tobie
Copy link
Collaborator Author

tobie commented Sep 27, 2017

I suspect it's easier to wait for mixins and delay this a little bit, though if tooling can start requiring it that would be good of course.

Agree on both counts.

@tabatkins
Copy link
Contributor

It's committed now speced/bikeshed@a1b4829 as a Complain About option. I need to do some refactoring to enable me to turn this on by default. (Right now, my "default" mechanism gets wiped out if anything sets the value, so it doesn't handle things that can accumulate, like Complain About.

This was referenced Sep 30, 2017
kenrussell added a commit to kenrussell/WebGL that referenced this pull request Jul 19, 2018
This extended attribute has been required by Web IDL since
whatwg/webidl#423 . In order for WebGL to be accessible by web workers
using OffscreenCanvas, the attribute being added to all WebGL
interfaces is:
[Exposed=(Window,Worker)]

Fixes KhronosGroup#2571 .
kenrussell added a commit to kenrussell/WebGL that referenced this pull request Jul 26, 2018
This extended attribute has been required by Web IDL since
whatwg/webidl#423 . In order for WebGL to be accessible by web workers
using OffscreenCanvas, the attribute being added to all WebGL
interfaces is:
[Exposed=(Window,Worker)]

Fixes KhronosGroup#2571 .
kenrussell added a commit to KhronosGroup/WebGL that referenced this pull request Jul 26, 2018
* Add [Exposed] Web IDL attribute to all WebGL interfaces.

This extended attribute has been required by Web IDL since
whatwg/webidl#423 . In order for WebGL to be accessible by web workers
using OffscreenCanvas, the attribute being added to all WebGL
interfaces is:
[Exposed=(Window,Worker)]

Fixes #2571 .

* Address review feedback from jgilbert
aarongable pushed a commit to chromium/chromium that referenced this pull request Aug 23, 2019
This CL makes the code align with making Exposed mandatory for interfaces.
See the following for more details:
web-platform-tests/wpt#18382
whatwg/webidl#423

Change-Id: I293e80cd0d953f2f47480f838eecd5f588ec6d80
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1768918
Reviewed-by: Luke Bj <lukebjerring@chromium.org>
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#689988}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Investigate removing [PrimaryGlobal] and requiring [Exposed]
5 participants