do we really need navigator.clipboard.platform?

[gked]

Just curious about rationale for navigator.clipboard.platform.
There are ways to get this information today. Exposing platform hook on clipboard interface seems odd.

[dway123]

navigator.clipboard.platform is intended to be a simple and consistent way to detect the clipboard target that the user is currently on. This is because using navigator.platform + navigator.userAgent currently is fairly complex to use and sometimes inconsistent between browsers, as mentioned here. Detecting a platform (OS) in a browser-independent way through navigator.platform + navigator.userAgent often requires complex regular expressions that would not be obvious to someone simply reading MDN or the spec. Using raw clipboard access with navigator.clipboard.platform could allow a web application to simply check the clipboard backing, which varies less than navigator.platform (ex. "x11 Linux" could be a consistent return value regardless of computer architecture (arm v. ppc v. intel, and 32-bit v. 64-bit)). Additionally, ChromeOS can sometimes be harder to detect, as it's sometimes labelled as Linux, and this would require only one API instead of 2 to detect the platform.

Here is some sample code showing how navigator.clipboard.platform may be a bit cleaner:

// Through navigator.clipboard.platform, simple equality checks may be used.
if (navigator.clipboard.platform === 'Windows') {
  // Windows code.
} else if (navigator.clipboard.platform === 'MacOS') {
  // Mac code.
} else if(navigator.clipboard.platform === 'Android') {
  // Android code.
}

// Through navigator.platform + navigator.userAgent, detection is slightly more complex
// source: https://stackoverflow.com/questions/38241480/detect-macos-ios-windows-android-and-linux-os-with-js
const windowsPlatforms = ['Win32', 'Win64', 'Windows'];
const macOsPlatforms = ['Macintosh', 'MacIntel'];

if (windowsPlatforms.indexOf(navigator.platform !== -1) {
  // Windows code.
} else if (macOsPlatforms.indexOf(navigator.platform) !== -1) {
  // Mac code.
} else if(/Android/.test(navigator.platform.userAgent)) {
  // Android code.
}

That said, navigator.platform already works and is well documented. There exist libraries like platform.js that make this easy to consume, and plenty of content already describes how to detect a platform.

While this API may be more direct and simple to use for clipboard, it could certainly also be an unnecessary API that duplicates existing behavior, which increases maintenance costs and may add confusion. It also certainly isn't required to meet the goals for Raw Clipboard Access.

Summary:
I'm unsure that it's completely necessary, but there are pros and cons. This is still open for discussion, and I've filed an issue asking for feedback/thoughts as well from TAG regarding this.

Pros:

• simpler to detect clipboard backing platform
• more consistent to detect clipboard backing platform

Cons:

• extra API to maintain for browsers
• extra API for developers to disambiguate (looks odd)

(Thank you for asking this question, and sorry for the wall of text.)

[rniwa]

I'm confused. Is this about raw clipboard API proposal? The current specification doesn't define this IDL attribute, right?

The platform name as currently proposed in https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md#navigatorclipboardplatform isn't workable because iOS and macOS pasteboards are interchangeable via continuity.

[dway123]

Yes, I think this is about the raw clipboard API proposal (and responded assuming so, but could certainly be wrong).

Do iOS and MacOS have the same representation for supported formats? Assuming so, I've updated the explainer appropriately to remove the iOS mention. If there's a better name for the backing clipboard for MacOS/iOS, it may be possible that we should opt for that as well.

[gked]

I'm confused. Is this about raw clipboard API proposal? The current specification doesn't define this IDL attribute, right?

The platform name as currently proposed in https://github.com/dway123/raw-clipboard-access/blob/master/explainer.md#navigatorclipboardplatform isn't workable because iOS and macOS pasteboards are interchangeable via continuity.

yeah, wrong repo. Sorry for the confusion.

@dway123 anyway we could move the explainer to WICG repo? I can re-open the issue there if need be.

[dway123]

Ah yeah, I'll try to move the explainer to WICG. Thank you for the suggestion. (I've never done this before, so I may take a bit of time to do so).

Also, regarding more context for navigator.clipboard.platform, it's also possibly necessary as updating navigator.platform and navigator.userAgent to support Wayland may not be web compatible. Sites currently regex match "Linux" to detect sites running over Linux, but if some site were to check for whether "X11; Linux" was contained in navigator.userAgent, and Wayland support were to be added, such that "Wayland; Linux" were to be supported, there may be some sites that may unnecessarily break.

[dway123]

I've started a WICG thread here. Thanks!

[garykac]

Closing this here since the discussion belongs (and has moved to) the https://github.com/WICG/raw-clipboard-access repo.

Specifically: WICG/raw-clipboard-access#6