Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/whatwg/html/issues/6059 below:

Should we delete or otherwise neuter globalThis in worklets? · Issue #6059 · whatwg/html · GitHub

The worklets spec currently claims

The following techniques are used in order to encourage authors to write code in an idempotent way:

• No reference to the global object, e.g. self on a DedicatedWorkerGlobalScope.

In the process of moving this to HTML in #6056, I noticed that this is no longer a true statement. Since the Worklets spec was written, the JavaScript specification has introduced the globalThis global, which points to the global this value/global object.

I see several options here:

1. Do nothing, and let globalThis continue to live and point to the WorkletGlobalScope object. The main justification for this is that the purpose of globalThis was to provide cross-environment uniformity, and we shouldn't counteract that. This would involve rephrasing that section of the spec to admit that you can store global state if you want to; the browser won't stop you.

2. Delete the globalThis property on WorkletGlobalScope creation, like we currently do for SharedArrayBuffer in some cases. This gets us back to the status quo when worklets were originally specced, at the cost of going against the spirit of the JS specification. (But not the letter; hosts are allowed to change global properties, just like JS code can.)

3. Say that the "global this value" in worklets is undefined, even though the global object is a WorkletGlobalScope. This would have the following more-subtle effects:

   • eval("this"), which evals this in sloppy mode global scope, would return undefined. I.e., this would plug the current way in which code can escape the strict/module-level global scope worklets are usually confined to. That means the global is really super-censored, even more than it ever has been.

   • hasOwnProperty('globalThis') would still return true (unlike with option (2)).

   • This would probably require ES spec updates, as currently the ES spec requires the value to be an Object. At a quick skim, however, it seems like nothing in the ES spec would break if we relaxed this constraint.

   • Probably this would be harder to implement than (2).

/cc @syg for ES side considerations; @nhiroki for Chrome worklet stuff; @bfgeek as worklets editor.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4