sounds useful.

we could just have [Exposed=Worker], [Exposed=Window] (default), [Exposed=Window,Worker]

Reassigning to heycam for consideration in WebIDL. Please reassign to me once either there is WebIDL syntax for this or it's been decided to only do this in prose, not WebIDL. Thanks!

Comment 2 can be tied with the new [Global] extended attribute I think.

This should also support having a class exposed on both and then have a partial class supported on just one.

Just looking at this again now.  Would [Exposed] only control whether an interface object is visible or not?

What I have been wanting to do is things like this:

[Exposed=Window,Worker] interface XMLHttpRequest { ... }

[Exposed=Window] partial interface XMLHttpRequest { ... responseXML ... }

So it would be more than that if I had my way.

Do we need more fine-grained management? For example, the Web Perf WG asked about including only _some_ APIs on their window.performance object, but not others (e.g., performance.now() everywhere, but not necessarily the statistics objects...)

It should be fine to allow [Exposed] on partial interfaces, as well as on individual interface members if that's needed.  But in terms of actual concrete effects, is hiding/exposing the interface object property on the global the only thing that needs to be done?

Yeah I think so. That's all that interface XMLHttpRequest {} does after all. This is just a way to scope that to particular globals.

https://github.com/heycam/webidl/commit/b38006ce3682fc07c1be52a49130bea5e42e7c78

Summary:
  * Window should change its [Global] to [PrimaryGlobal]
  * the [Global] on SharedWorkerGlobalScope and DedicatedWorkerGlobalScope
    should become [Global=Worker]
  * you can use [Exposed=Worker] or [Exposed=Window,Worker] as appropriate
    on interfaces, interface members, partial interfaces, and dictionaries
    that have constructors.

Cameron, can we tag [Global=Worker,DedicatedWorker]? It seems we need granularity like that for certain features. Especially with the new ServiceWorkerGlobalScope.

Sure:

https://github.com/heycam/webidl/commit/3aa9313b571b7f4b86846cc025d0f7e967eea1b1

heycam: Why do you have this restriction?:

# If [Exposed] appears on an overloaded operation, then it must appear on all 
# overloads, with the same identifier list.

Consider e.g. APIs that in workers take a string or an integer, but in Windows take a string, an integer, or a DOM node.

It would have been a bigger change to allow the set of operations that are involved in overloading to be different, so I decided to disallow it until we're sure we need it.  Do we need it? :)

Checked in as WHATWG revision r8425.
Check-in comment: Update the spec to say what's exposed to workers: take 1
http://html5.org/tools/web-apps-tracker?from=8424&to=8425

Ok, I welcome review of the above. I'm especially interested in how I used it here, where there's an attribute with a different definition for workers than it has for Window:

   http://whatwg.org/html/#the-messageevent-interfaces

(In reply to Ian 'Hixie' Hickson from comment #17)
> Ok, I welcome review of the above. I'm especially interested in how I used
> it here, where there's an attribute with a different definition for workers
> than it has for Window:
> 
>    http://whatwg.org/html/#the-messageevent-interfaces

Ah so that is a problem, I guess.  Currently I disallow any duplicate attribute names on an interface, not looking at [Exposed].  Given that the dictionary still has the union, and that as with XHR.send() still having Document in the types is OK, do you need to split the attribute in two here?

I guess not? But shouldn't it be non-conforming for me to have an attribute that returns an interface type that isn't exposed?

The dictionary is fine because the interface isn't exposed so you can't possibly set the dictionary to a value that uses the interface. But the attribute in theory could be used by a user agent in a way that returns that interface even in a worker, despite the interface not being exposed... I dunno, it just seemed like something that should be done for completeness.

How about this, is this ok?:

Checked in as WHATWG revision r8430.
Check-in comment: Try doing this a different way (MessageEvent.source exposure)
http://html5.org/tools/web-apps-tracker?from=8429&to=8430

That approach does not work for FormData of which the constructor takes a HTMLFormElement. Given that FormData is exposed in Window and Worker I think it should be okay if HTMLFormElement ends up being impossible in the Worker context.

For arguments, I don't think there's a problem with just exposing them everywhere. It's black-box indistinguishable from not exposing them (unless it's a constructor that only takes unexposed types, since then it'd be uncallable, but I'm not aware of any such cases). It's return values I'm more worried about.

(In reply to contributor from comment #20)
> Checked in as WHATWG revision r8430.
> Check-in comment: Try doing this a different way (MessageEvent.source
> exposure)
> http://html5.org/tools/web-apps-tracker?from=8429&to=8430

This has the same problems; the checking of duplicate attribute (and operation) identifiers is done on the whole set of members, not looking at [Exposed].

How about I just add a conformance requirement that says for an object associated with a global with a particular global name, only objects with interfaces that are exposed in that global may be returned?

That would work.

Ok, I've moved MessageEvent.source back. I think that concludes everything that I need to do for this bug. Sending back to heycam for the comment 23 update.

Checked in as WHATWG revision r8444.
Check-in comment: Ok, go back to exposing MessageEvent.source in one form everywhere, relying on WebIDL for the rest of the logic here
http://html5.org/tools/web-apps-tracker?from=8443&to=8444

The way we do this is by checking the current global object, defined in HTML. See https://xhr.spec.whatwg.org/ for an example if you need this.