This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/multipage/webappapis.html Multipage: https://html.spec.whatwg.org/multipage/#the-navigator-object Complete: https://html.spec.whatwg.org/#the-navigator-object Referrer: https://html.spec.whatwg.org/multipage/ Comment: Consider standardizing navigator.oscpu Posted from: 98.110.194.132 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:37.0) Gecko/20100101 Firefox/37.0
Note discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1120892
I did a fair bit of digging in the httparchive data, this was the worst thing I found, from http://www.littlealchemy.com/js/alchemy.js: navigator.userAgent.toLowerCase().indexOf("firefox") > -1 && navigator.oscpu.toLowerCase().indexOf("windows nt 6.1") > -1 ... That's the only really bad case I found, but there's bound to be more somewhere out there. Any ideas about the compat constraints here, would the empty string or an alias of vendor.platform work?
How many browsers implement it?
Just Firefox, but we can't drop it given site code of the sort in comment 2.... Empty string would make whatever sniffing is involved fail (not throw, which would be bad, just return false), but maybe that's OK. Past that, I'm not sure what values this thing returns right now as compared to navigator.platform (I assume that's the one you meant?). It might be possible to alias navigator.platform depending on what regexps people are matching against this string.
Right, I meant navigator.platform. It would be nice to have a use counter-like number estimating the impact of removal for Firefox, but I realize that it's not really possible since you'd have to track how the string is used in the JS engine :/
navigator.cpuClass is similar, so I've asked the IE team to take a look: https://connect.microsoft.com/IE/feedbackdetail/view/1087515/consider-removing-navigator-cpuclass
If only one browsers implements it, it seems like the shortest and safest path to interop here is for the other browsers to not do anything, and for that browser to spew console warnings, send advocacy e-mails warning of the impending doom of this feature, and add a tracking counter to measure how use of this property drops over time, then finally remove it.
Just to be clear, that's a path to interop that's measured in many years. So if you're really aiming for "shortest", it's probably not it. It's the least-effort one for non-Firefox browsers and spec authors, of course.
Now that we have "Gecko compatibility mode" for navigator, this seems worth fixing. https://github.com/whatwg/html/pull/1017