This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Instead of Crypto, WorkerCrypto, and RandomSource, have this: [Exposed=Window,Worker] interface Crypto { readonly attribute SubtleCrypto subtle; ArrayBufferView getRandomValues(ArrayBufferView array); };
You probably also need [Exposed] for various other interfaces to make sure they are exposed in workers.
(In reply to Anne from comment #0) > Instead of Crypto, WorkerCrypto, and RandomSource, have this: > > [Exposed=Window,Worker] > interface Crypto { > readonly attribute SubtleCrypto subtle; > ArrayBufferView getRandomValues(ArrayBufferView array); > }; This is not equivalent to what is in the spec. According to http://heycam.github.io/webidl/#Exposed , Exposed only applies to an interface if it's part of the global scope (eg: exposed on the global scope) Your proposed modifications mean it's no longer "window.crypto.subtle" or "worker.crypto.subtle", but instead, "window.subtle", which is not the same, nor necessarily desirable. If Crypto was a Constructable-object, yes, it would mean you could do "new Crypto" from the context of a worker - except it's not. Unless I'm missing something, isn't this a WontFix? (In reply to Anne from comment #1) > You probably also need [Exposed] for various other interfaces to make sure > they are exposed in workers. Did you have any interfaces in mind? None of the interfaces are constructible, which would be the only thing that exposing them would seem of value. Even still, using [Exposed] would seem wrong, because the global object does *not* implement the interfaces specified.
The behavior of [Exposed] depends on what it's specified on. If specified on an interface, then it affects whether the corresponding interface object can be retrieved via a property on the global. So this: [Exposed=Window,Worker] interface SubtleCrypto { // stuff }; would mean that "SubtleCrypto" at global scope gives the relevant interface object in both window scopes and workers. If specified on an interface member, it controls whether the member is visible in instances of the interface that have the corresponding global. So: interface Crypto { [Exposed=Window,Worker] readonly attribute SubtleCrypto subtle; }; would mean that Crypto instances in both windows and workers would have a .subtle property. That said, I'm not a huge fan of the way webidl handles lack [Exposed] on interface members right now. I filed bug 25495 on that.
Ryan, [Exposed] != implements. [Exposed] indicates whether the class/interface is available within a global environment.
The resolution of Bug 25626 will ultimately leave this as a syntactic sugar between WorkerCrypto, RandomSource, and Crypto, since the only interface remaining will be those three.
It's not quite syntactic sugar, since Crypto vs WorkerCrypto is easily detectable, right?
In order to progress towards exit to Last Call for the Web Crypto API, the chair suggests the following resolution for that bug. Resolution : Bug RESOLVED as WONTFIX. Based on the estimation that this change would be synthetic sugar. If none objects before the 20th of Oct @20:00 UTC, this resolution will be endorsed.
Comment 6 pointed out that interpretation was false. Also, you need Exposed if you want anything to appear in workers at all.
Anne is correct. The spec as written doesn't actually have any APIs at all in workers. In Gecko this hasn't been an issue so far because we don't support this API in workers yet, but once we start implementing that we will simply be unable to do what the spec currently says.
Here is an updated version of comment 0 to make this easier for the WG: [NoInterfaceObject] interface GlobalCrypto { readonly attribute Crypto crypto; }; Window implements GlobalCrypto; WorkerGlobalScope implements GlobalCrypto; [Exposed=(Window,Worker)] interface Crypto { readonly attribute SubtleCrypto subtle; ArrayBufferView getRandomValues(ArrayBufferView array); }; [Exposed=(Window,Worker)] interface SubtleCrypto { ... }; [Exposed=(Window,Worker)] interface CryptoKey { ... };
This makes sense to me. I suggest we go with the proposal in comment#10.
In order to progress towards exit to Last Call for the Web Crypto API, the chair suggests the following resolution for that bug. Resolution : Bug Closed. The editors will implement the suggestion edited in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25390#c10 If none objects before the 20th of Oct @20:00 UTC, this resolution will be endorsed.
https://dvcs.w3.org/hg/webcrypto-api/rev/810285715051