Skip to content

lib: make Navigator WPT-compliant - #65119

Open
avivkeller wants to merge 1 commit into
nodejs:mainfrom
avivkeller:wpt
Open

lib: make Navigator WPT-compliant#65119
avivkeller wants to merge 1 commit into
nodejs:mainfrom
avivkeller:wpt

Conversation

@avivkeller

Copy link
Copy Markdown
Member

Adds appCodeName, appName, appVersion, and product to the navigator, so it can pass WPT. onLine is also defined in the spec, so it's added as well.

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/web-standards

@nodejs-github-bot nodejs-github-bot added the needs-ci PRs that need a full CI run. label Aug 7, 2026
@avivkeller avivkeller added the web-standards Issues and PRs related to Web APIs label Aug 7, 2026
Signed-off-by: avivkeller <me@aviv.sh>
@panva

panva commented Aug 7, 2026

Copy link
Copy Markdown
Member

We discussed these before. The legacy properties were proposed in #50521, which was closed because there was no clear Node.js use case or interoperability benefit.

navigator.onLine was proposed in #50224 and was blocked. The concerns were that online status is unreliable in Node.js, always returning true is not useful, and an implementation should also provide the online and offline events.

WinterTC55 Navigator Registry also says that non-browser runtimes should not implement these legacy properties. If they do, they should implement the whole compatibility group with a matching browser-style userAgent.

I don't think passing these WPT tests is enough reason to revisit those decisions unless there is new use case or compatibility issue that wasn't considered in #50521 and #50224.

@avivkeller

Copy link
Copy Markdown
Member Author

I'm aware that previous attempts to add these properties were rejected, but I still think there is value in supporting them, particularly for Web Platform compatibility.

Passing the relevant WPTs means that code relying on navigator, including its legacy properties, can behave consistently when run in Node.js. While these properties are legacy, they remain widely available across browsers and may still be relied upon by existing code.

We've historically been willing to retain legacy functionality, such as punycode, as doing so provides compatibility with existing programs. I don't see this as really that different.

These properties add a small amount of effectively unchanging values. Given the low maintenance cost, I think supporting them for compatibility with widely available Web APIs is something we should be open to.

@avivkeller

Copy link
Copy Markdown
Member Author

Even if other runtimes such as Deno and Bun don't support these properties, I don't think that should necessarily prevent us from doing so. There are 450K+ GitHub code results referencing them. While much of that code is undoubtedly intended for browsers, supporting these properties increases the amount of "general-purpose" JavaScript that can run in Node.js.

@avivkeller avivkeller added the discuss Issues opened for discussions and feedbacks. label Aug 7, 2026
@codecov

codecov Bot commented Aug 7, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.31%. Comparing base (e2d7b34) to head (070ca92).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #65119      +/-   ##
==========================================
- Coverage   90.31%   90.31%   -0.01%     
==========================================
  Files         759      759              
  Lines      248290   248342      +52     
  Branches    46859    46868       +9     
==========================================
+ Hits       224241   224280      +39     
- Misses      15472    15511      +39     
+ Partials     8577     8551      -26     
Files with missing lines Coverage Δ
lib/internal/navigator.js 99.07% <100.00%> (+0.29%) ⬆️

... and 37 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

discuss Issues opened for discussions and feedbacks. needs-ci PRs that need a full CI run. web-standards Issues and PRs related to Web APIs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants