Navigator APIs

[legendecas]

There are lots of APIs defined on the Navigator object. For now, the common minimum API merely defines navigator.userAgent as part of the common APIs that WinterCG runtimes are interested in implementing.

However, it is being proposed to add more properties to Navigator in Node.js for usefulness (e.g. Navigator.hardwareConcurrency) and legacy compatibility (e.g. constant Navigator.appVersion version)

Current implementation status:

API/Attribute Name	Node.js	Deno	Cloudflare Worker	Bun
Navigator.userAgent	✅	✅	✅	✅
Navigator.hardwareConcurrency	✅	✅	❌	✅
Navigator.platform	✅ nodejs/node#50385	❌	❌	✅
Navigator.language	nodejs/node#50303	✅	❌	❌
Navigator.languages	nodejs/node#50303	✅	❌	❌
Navigator.onLine	nodejs/node#50224	❌	❌	❌
NavigatorID mixin (excluding Navigator.userAgent and Navigator.platform)	nodejs/node#50521	❌	❌	❌

I believe the common APIs of Navigator should be extended to include attributes that were shipped in more than two runtimes. Also, if there are strong push-backs on adding the above APIs to the common minimum API, we should be wary of shipping them to reduce the gaps between the runtimes.

[GeoffreyBooth]

If you look at https://developer.mozilla.org/en-US/docs/Web/API/Navigator, there are many more things available on navigator than just primitive strings and numbers. There are full-blown APIs like navigator.clipboard and navigator.share() and so on. Most of these aren’t obviously useful to server-side runtimes but I can imagine some of them might actually be; like a command-line tool might potentially do something useful with the clipboard, or pop up the native OS’ Share dialog.

[legendecas]

These methods are not present at the WorkerNavigator, which is the navigator object in web worker contexts. The WorkerNavigator is a subset of the main context Navigator, which makes more sense in a headless environment.

So I would avoid expanding the common-minimum-api to be the full set of Navigator, but limit it to be a subset of WorkerNavigator.

[GeoffreyBooth]

So I would avoid expanding the common-minimum-api to be the full set of Navigator, but limit it to be a subset of WorkerNavigator.

Oh sure, I wasn’t suggesting we include all those APIs in the common minimum. Just that we should perhaps rename this from “attributes” to some thing like “Navigator APIs” because some of the keys on navigator aren’t primitives.

[legendecas]

Sure, thanks for the suggestion!

[jasnell]

I think there's enough consensus among the runtimes that we should add at least some of these. I will say that workers is likely unable to ever add navigator.hardwareConcurrency (we have no need given the way we virtualize and time-share CPU), and we don't really have a strong case for navigator.platform, navigator.language, and navigator.languages, and navigator.onLine doesn't really make sense for the always-on edge environment... but if a particular set of attributes are implemented by at least two of the runtimes then we can make an argument to include them.

[GeoffreyBooth]

if a particular set of attributes are implemented by at least two of the runtimes then we can make an argument to include them.

Node, Deno and Bun all implement the following (reference 1, reference 2):

• navigator.hardwareConcurrency
• navigator.platform
• navigator.userAgent

Node and Deno additionally implement:

• navigator.language
• navigator.languages

navigator.userAgent is already in the minimum common API, which makes sense; its very purpose is to identify the current runtime, which seems like an important thing to have a cross-platform way to do.

Likewise navigator.platform, for determining the current OS and chipset, is another thing that seems really useful to have a cross-platform API for.

I think navigator.hardwareConcurrency‘s primary value is in letting you know how many cores are available, which would influence how many threads get spawned (?). I can understand if this isn’t relevant to workerd, or could it just always return 1 for this? But seeing as we have a cross-platform API for worker threads, it feels logical to have a cross-platform way to know how many threads should be spawned.

[andreubotella]

Note that Deno Deploy supports navigator.hardwareConcurrency, despite not supporting workers, and it seems to always return 1.

[legendecas]

Closed with https://github.com/wintercg/navigator-registry.

[ekwoka]

Most of these aren’t obviously useful to server-side runtimes but I can imagine some of them might actually be; like a command-line tool might potentially do something useful with the clipboard, or pop up the native OS’ Share dialog.

Definitely. Just running in the cloud, these aren't useful (or would be strange to use), but many runtimes, at least the ones most seem to refer to, are equally at home running locally for tooling.

I don't think there is an abundance of people using edge-runtime or cloudflare workers to run cli tools, but Bun and Deno do get some use, and of course, Deno.

And then there is also doing a runtime emulation of browser environments. Though, I think that case could more likely be simply polyfilled.

[ekwoka]

I will say that workers is likely unable to ever add navigator.hardwareConcurrency (we have no need given the way we virtualize and time-share CPU), and we don't really have a strong case for navigator.platform, navigator.language, and navigator.languages, and navigator.onLine doesn't really make sense for the always-on edge environment.

Would not simply providing them with "dummy" results be valuable? hardwareConcurrency just always returns 1, etc.

Or would it be better to not have them at all to make feature detection easier?

I guess I'd be torn between whether easy feature detection is better than being interface compliant (even if functionally incorrect)