Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

do we really need navigator.clipboard.platform? #104

Open
gked opened this issue Oct 12, 2019 · 6 comments

Comments

@gked
Copy link
Collaborator

@gked gked commented Oct 12, 2019

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

This comment has been minimized.

Copy link

@dway123 dway123 commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@rniwa rniwa commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@dway123 dway123 commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

@gked gked commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@dway123 dway123 commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@dway123 dway123 commented Oct 15, 2019

I've started a WICG thread here. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.