Support multiple user script worlds in the user scripts API

[rdcronin]

The user scripts API allows scripts to inject in a new "user script" world (in addition to the main world), which has slightly different properties than the isolated world content scripts inject in. From early discussions (e.g. this comment from issue #279 ), we have supported the idea of multiple user script worlds.

This issue tracks that work.

[Rob--W]

I am currently working on the implementation of multiple user script worlds in Firefox, and while examining Chrome's implementation more closely, I found an issue with the currently specified/implemented behavior for worldId.

The current spec is at https://github.com/w3c/webextensions/blob/main/proposals/multiple_user_script_worlds.md and describes worldId as follows:

 /**
+     * If specified, specifies a specific user script world ID to execute in.
+     * Only valid if `world` is omitted or is `USER_SCRIPT`. If `worldId` is
+     * omitted, the script will execute in the default user script world.
+     * Values with leading underscores (`_`) are reserved.
+     */
+    worldId?: string;

This description (and the spec in general) does not specify the worldId to use for the "default user script world".

Chrome's current implementation seems to use null for that. This causes issues in cases where null is ambiguous: the userScripts.update method ought to replace some properties, but because null is interpreted as "not explicitly specified", it is not possible to change worldId back to the default world.

Example (requires starting Chrome with --enable-features=ApiUserScriptsMultipleWorlds):

await chrome.userScripts.register([{
  id: "id",
  js: [{ code: "alert(0)" }],
  matches: ["https://example.com/*"],
  worldId: "x",
}]);
await chrome.userScripts.update([{
  id: "id",
  // Also weird: Chrome requires js to be set in update()
  js: [{ code: "alert(1)" }],
  worldId: null, // intent to change to default world
}]);
var scripts = await chrome.userScripts.getScripts({ ids: ["id"] });
console.log(scripts[0].worldId);
// Expected: null (default?)
// Actual: "x" (unchanged)

If we want to keep the default at null, it is technically possible to distinguish "property set" (=set to null) from "property not set" (= do not update) in Firefox's implementation. However, this is unusual and I would prefer a different solution that is easier to explain.

Last time we discussed the worldId format, I mentioned two options at #560 (comment)

• Defaulting to "" (empty string). Chrome's implementation currently throws.
• Using a constant such as "_DEFAULT". Devlin was not fond of exposing _.

Given this all, I propose to establish "" as the value for the default world's worldId.

[rdcronin]

Thanks, @Rob--W ! Agreed this is something we should fix, and I'm supportive of using the empty string ("") to represent the default world. If there are no objections, I'll make the change in Chromium.