Issue metadata
Sign in to add a comment
|
ServiceWorkers use "random" document to resolve URL registerServiceWorker and getRegistration |
||||||||||||||||||||||||
Issue descriptionthe "enteredExecutionContext" method doesn't return the correct context during microtask execution. The code assumes that it's safe to fallback to the current context, however, we might have an entered context, e.g., when some js code dispatches an event, and at the end of the event dispatch we'll execute microtasks. Then the js code is still the entered execution context, so we'll get a non-null context, which is, however, entirely unrelated to the service worker. I'd argue that microtasks should enter a context, it's however not trivially clear what context that should be - the context of the Promise constructor? The creation context of the microtask function? Putting the security label on this, because I could imagine that a more creative person can turn this into some code that takes over a service worker cross domain
,
Feb 24 2017
For the record it's a known spec issue that entry is not well defined during promise microtask execution: https://html.spec.whatwg.org/#enqueuejob(queuename,-job,-arguments) big red warning + https://github.com/whatwg/html/issues/1426 tracking issue. We could try to fix this but my plan is to prioritize killing the entry concept instead if possible.
,
Jun 3 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by jochen@chromium.org
, Feb 24 2017Status: Duplicate (was: Untriaged)