Chromium issue:
https://code.google.com/p/chromium/issues/detail?id=276813

Chrome use counter data:
https://www.chromestatus.com/metrics/feature/timeline/popularity/124

A comment in the spec says:
<!-- vendor: Mozilla and Safari only; always returns "" in Mozilla, and returns the fixed string "Apple Computer, Inc." in Safari -->

This is no longer accurate. Firefox and IE return "", Safari returns "Apple Computer, Inc.", Chromium-based browsers return "Google Inc." by default, but the Chromium-based Opera returns "Opera Software ASA".

Not having it at all doesn't seem like an option, as one finds many instances of 'navigator.vendor.' in the httparchive data, doing mostly things like navigator.vendor.indexOf("Apple") which would throw an exception.

It's possible that aligning on "" won't be possible, in which case it'll have to be like navigator.userAgent, but it's a good first attempt IMHO.

(In reply to Philip Jägenstedt from comment #1)
> Chromium issue:
> https://code.google.com/p/chromium/issues/detail?id=276813
> 
> Chrome use counter data:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/124
> 
> A comment in the spec says:
> <!-- vendor: Mozilla and Safari only; always returns "" in Mozilla, and
> returns the fixed string "Apple Computer, Inc." in Safari -->
> 
> This is no longer accurate. Firefox and IE return "", Safari returns "Apple
> Computer, Inc.", Chromium-based browsers return "Google Inc." by default,
> but the Chromium-based Opera returns "Opera Software ASA".
> 
> Not having it at all doesn't seem like an option, as one finds many
> instances of 'navigator.vendor.' in the httparchive data, doing mostly
> things like navigator.vendor.indexOf("Apple") which would throw an exception.
> 
> It's possible that aligning on "" won't be possible, in which case it'll
> have to be like navigator.userAgent, but it's a good first attempt IMHO.

I strongly oppose any decision that would completely remove navigator.vendor(s). There is a simple contract when a manufacturer releases a product to the public. The company puts its name on it. And the user knows who made the software being used. What are you trying to achieve with this?

There is a very good reason developers or analytic companies use it. That is one of the most useful token to help verify engines or browsers with accuracy, given that the user-agent is completely unreliable and getting worse. Feature detection is not sufficient alone when it come to very specific bugs. Attempts to remove everything to the point where browsers manufacturer cannot be traced is really not a solution. It will likely lead to more analytics distortion in terms of browser usage data and create more problem that it solves. At its core it's borderline unethical if that reasoning applied to any other type of software.

What is the exact motive for this action? The chromium issue give no reasons for it.

Most importantly, I want the spec to describe what must be implemented in order to support real Web content, and at minimum navigator.vendor must be a string.

navigator.vendor currently allows you to distinguish between WebKit-based ("Apple Computer, Inc.") and Chromium-based ("Google Inc.") browsers, but both IE and Firefox return "". I tried a few Samsung and HTC phones and those browsers return "Google Inc."

We decided to make navigator.vendor return "Opera Software ASA" in our Chromium-based Opera 14+, but we're revisiting that decision since it has some risk but really no benefits other than being truthful.

Note that we haven't made the decision to change navigator.vendor in Opera or in upstream Chromium yet, I wanted to get the spec bug started first, since *something* needs to be specified regardless.

(In reply to Philip Jägenstedt from comment #3)
> navigator.vendor currently allows you to distinguish between WebKit-based
> (“Apple Computer, Inc.”) and Chromium-based (“Google Inc.”) browsers, but
> both IE and Firefox return “”. I tried a few Samsung and HTC phones and
> those browsers return “Google Inc.”

I believe IE and Firefox’s moves are a mistake. But it was too late for me to comment. 

Webkit and Blink are two different engines, sometime with the same features yet different behaviors. And we keep seeing browser vendor insisting on lying about the actual engine used at the UA level like Midori’s phony Chrome version:
https://answers.launchpad.net/midori/+question/248480

How would you expect a developer to deal with this lying non-sense and no reliable means to detect a foolish UA?

> We decided to make navigator.vendor return “Opera Software ASA” in our
> Chromium-based Opera 14+, but we’re revisiting that decision since it has
> some risk but really no benefits other than being truthful.

What benefits is there to pretend to be a unicorn engine made by an anonymous entity?

I have cited some benefits. You can’t say there are no benefits when I say I do use it for good reasons, and 7% use it. That’s rather dismissive of developers at large and ignoring or questioning their motives.

Many JS libraries do at least one exception on the user agent, but all of this is going to be broken given IE’s recent mood changes for their so called “interoperable user agent”. Which by the way, forces all good developers to fix their detection and reward the sloppy ones...

> Note that we haven’t made the decision to change navigator.vendor in Opera
> or in upstream Chromium yet, I wanted to get the spec bug started first,
> since *something* needs to be specified regardless.

Could you please expand on the assumed risks you are referring to?
You haven’t answered that question.

----

IMO there needs to be an “engine” name token somewhere designed to help developers resolve bugs and properly identify at least the engine name and the vendor, instead of having them trying to sniff the UA and play these endless hide-and-seek games.

To differentiate between WebKit-based and Chromium-based browsers, you can check if window.chrome is defined. But it really depends on what you're trying to do, do you have a piece of code using navigator.vendor to illustrate the problem?

For Opera, having a different navigator.vendor than other Chromium-based browsers risks taking the wrong code path, and this came up in an effort to reduce the number of Web-facing differences we have. There's still window.opr and OPR in the user agent string to distinguish it.

The spec needs to say something about navigator.vendor, feel free to propose your own spec text. "" is just the simplest thing that has a chance of working.

If I could, I would remove navigator.* entirely. Pages shouldn't be able to distinguish different browsers. The browsers should all appear identical to pages. Any differences should be bugs, IMHO. That's the whole point of having a spec: interoperability.

Not having navigator.vendor at all isn't an option, so I guess start with the empty string and see if Chromium/WebKit can successfully align with that?

(In reply to Ian 'Hixie' Hickson from comment #6)
> If I could, I would remove navigator.* entirely. Pages shouldn't be able to
> distinguish different browsers. The browsers should all appear identical to
> pages. Any differences should be bugs, IMHO. That's the whole point of
> having a spec: interoperability.

Ian, I am sorry to say but your statement is very ignorant of the challenges we face as developers, and very disappointing in that way.

You are free to believe in irrational and unpractical viewpoints. Meanwhile, some of us developers face the real world with web browsers full of bugs, specific un-specced behaviors and cross-incompatible crap to deal with.

Until we have reached actual bug free interoperability is 2050, your statement is a ridiculous utopia that may not ever exist. I'd ask that you put yourself in the developer's shoes and not lecture developers on their needs. 

I am trying to help the user as much as you are here. Needless to say, I don't enjoy at all having to detect all this stuff. I do it because I care about my websites working everywhere. And whether you like the prospect or not, finding hacks around bugs is sadly part of our daily routine as developers. Compatibility on mobile is bad on so many levels, this isn't a choice. Tools like Modernizer are good and the proper way to handle things but can't cover everything.

I spend over two full month developing a script which combine feature detection with device and browser detection to help my needs for various mobile features. So I have done my work in that area, and I am well informed about the past mistakes made by developers as well as having corrected some of them. I eventually intend to release the script as open source, because I see so many mistakes being made in browser detection that I'd like to help. And it does much more that telling what the browser is. It covers zoom, viewport, touch behavior, desktop mode handling for mobile etc. But can't simply rely on browser features for that. A couple tokens as I mention can be essential for some detection aspect.

That's the reality I'd like you to also live in.

Specific examples of how you're using navigator.vendor would be helpful.

If I were forced to categorize engines, I'd probably try to combine as many differences as possible -- Element.ms/moz/webkitMatchesSelector, moz/webkitRequestAnimationFrame, Document.webkitFullScreenKeyboardInputAllowed, WebKitNamespace, WebKitPoint, window.chrome, window.opr, bits of navigator.userAgent, etc. -- and weigh them together so that no individual change is enough to mis-identify an existing engine. It will still break eventually if not maintained, of course, and any new engine would hopefully in an "unknown but with no workarounds applied" category.

(In reply to Bruno Racineux from comment #8)
> I am trying to help the user as much as you are here. Needless to say, I
> don't enjoy at all having to detect all this stuff. I do it because I care
> about my websites working everywhere. And whether you like the prospect or
> not, finding hacks around bugs is sadly part of our daily routine as
> developers. Compatibility on mobile is bad on so many levels, this isn't a
> choice. Tools like Modernizer are good and the proper way to handle things
> but can't cover everything.


So the reality that browser developers face is this:  if scripts like yours become widely used, we end up being unable to make things more interoperable in the future, because the Web ends up depending on having behavior A if navigator.userAgent/vendor/etc. contains a certain string but behavior B if it doesn't.  In other words, having content that presumes bugs based on user-agent names in *current* versions of browser engines leads to engines having to make those behavior differences permanent.

So, in a sense, we're asking you to deal with things being more painful now so that they can be less painful in the future.

It's ok to use sniffing (or hacks where you use one bug to work around another) for old versions of browser engines, since in that case you know what version the bugs go away in (and, in the case of hacks that tie bugs, know that they go away in the same version).

It's also ok to work around bugs in ways that will continue to work when the bug is fixed, but it requires very good knowledge of the relevant standards to know what those ways are.

But if you're having trouble with current versions of browser engines, what we most want you to do is raise the issues that you're having so that we can fix them.

If you ship production content that depends on browser engines being different, we'll try to break that content if we can, in order to have a single standard that browser engines implement, so that future developers don't have to deal with these problems.  But if too many of our users care about your content working, we may end up being stuck with different behaviors tied to navigator.* strings forever.  (So far we've usually managed to get away with breaking the content eventually.)

(In reply to Philip Jägenstedt from comment #9)
> Specific examples of how you're using navigator.vendor would be helpful.
> 
> If I were forced to categorize engines, I'd probably try to combine as many
> differences as possible -- Element.ms/moz/webkitMatchesSelector,
> moz/webkitRequestAnimationFrame,
> Document.webkitFullScreenKeyboardInputAllowed, WebKitNamespace, WebKitPoint,
> window.chrome, window.opr, bits of navigator.userAgent, etc. -- and weigh
> them together so that no individual change is enough to mis-identify an
> existing engine. It will still break eventually if not maintained, of
> course, and any new engine would hopefully in an "unknown but with no
> workarounds applied" category.

It needs near unbreakable combos of differences indeed, both features and properties. Values like navigator.vendor and navigator.platform are crucial in reliable detection, especially when engines are being forked. I don't see it breaking that easy, unless you start messing with 'vendor' and give me another headache. Like I said, I did extensive research on this and countless tests on all emulators and browsers I could get my hands on.
https://twitter.com/hexalys/status/490032119020658688

I use the 'Google' and 'Apple' token extensively in a dozen instances. I am not really concerned with Opera in particular. If you were to align with Chrome and use Google Inc for Opera that would be ok given that they are the rendering engine. Though like I said I think that the standard should have navigator.engine too in, which would make Opera:

navigator.engine = 'Blink';
navigator.vendor = 'Opera Software ASA';

But the distinction between 'Google Inc.' and 'Apple Computers, Inc.' is a crucial one to distinct Webkit from Android Stock, Chromium or Blink. 'window.chrome' alone is not reliable and missing from some Blink browsers. See one of my conversation correcting some incomplete assumptions made: https://twitter.com/brothercake/status/404098282843955201

And yes I am aware it would have to be maintained, and possibly made versionless or evergreen. That said besides a couple new mobile enginesin the worls, I don't picture anyone daring to come up with new engine from scratch at this point other than forking existing engines.

I would happy to solve these issues of bad code path for everyone and helping standards with a long term solution for once and for all. Removing more stuff here is not helping though. It's patching things on assumptions, making our jobs more difficult that it already is, and breaking 10.000s of scripts on screwing with the entire ecosystem of analytics in place.

If you want to see what people do with it, see for yourself:
https://github.com/search?l=javascript&q=%22navigator.vendor%22&ref=advsearch&type=Code

> So the reality that browser developers face is this:  if scripts like yours
> become widely used, we end up being unable to make things more interoperable
> in the future, because the Web ends up depending on having behavior A if
> navigator.userAgent/vendor/etc. contains a certain string but behavior B if
> it doesn't.  In other words, having content that presumes bugs based on
> user-agent names in *current* versions of browser engines leads to engines
> having to make those behavior differences permanent.

You are making a lot of inaccurate assumptions. Most of such concerns do not apply. In regard to this bug thread. I am talking about giving accurate data of what the engine and other device characteristics are in reliable manner. That has nothing to do with differences like vendor that *should* be different anyway.

What people do with the properties I would provide is subject to misuse just like anything else. Anyone can misuse feature detection if they want to. Modernizr has false positive it can't solve and has its own issues. My attempt here is to do a similar job and provide additional device and browser information, as well tools such as:

- Mobile device detection with webview or standalone mode, or touch simulation and/or simulators.

- Detection of spoofed modes for mobile, when desktop mode is requested.
(because a responsive site is incapable of adjusting on its own in advance)

- Screen rotation polyfill for mobile, and ways to set a custom viewport sizes or fixed size on demand.

-  “Polyfill” for browsers that lack support or present bugs with the ‘interactive’ or other document states.

- Mobile device detection by categories with accurate CSS Screen size and DPR distinctions (except Safari desktop which of course keep believing in providing a fictional DPR no matter the actual screen size).

- Zoom detection with roughly 90% accuracy with distinction between zoom-scale, zoom-size and text-zoom.

- Detect Windows snapped mode, vs windowed mode, maximized, presentation mode or Metro mode etc.

- DoNotTrack (which was completely unreliable until Firefox 32 and for which you still can’t even agree on where that should be placed so it’s in two different places) https://twitter.com/hexalys/status/552224766300413952

- Assess whether a mobile device has 300ms delay or is in fastclick context.

- Partial Performance Timing Polyfill notably for PageSpeed measurement on the Analytics platform.

And to an extend, bad bots detection, plugins etc... giving all of this as organized analytics data for analysis, debugging or security purpose in google analytics fashion.

Now that script can start and rely upon some of those early detection signal,
and little use of the user agent except for the browser version and other verifications.

With all that said, I think I am in a good position to identify where all those browser differences are.

> But if you're having trouble with current versions of browser engines, what
> we most want you to do is raise the issues that you're having so that we can
> fix them.

I already do. But I don’t have two years to spare until a bug is looked at or fixed either, here is one: https://bugzilla.mozilla.org/show_bug.cgi?id=1022006
Or check my activity for yourself, if you must be convinced I am not a dummy.
http://stackoverflow.com/users/1647538

I recall that I should report 3 flexbox bugs by now, and I do participate in mailing for various things I see broken or inadequate. I have participated on Modernizr issue along my work to make sure I get it right, to either improve or correct things that can't be properly detected. As well being involved on accessibility matters. On top of trying to make living and get actual work done.

So thank you for you concerns in giving a basic noob lecture, but I am well informed on a lot of these matters and not exactly a newbie at this.

Bruno, do you have a link to a site that uses your library so that we can talk about concrete issues?

Bruno, the problem is that not all developers are as conscientious as you are.

I had a look at a few other Chromium-based browsers.

Cốc Cốc returns "Coc Coc". The Yandex browser returns "Yandex". These browsers have significant share in Vietnam and Russia respectively, and both also have distinguishing bits in the User-Agent string.

Comodo Dragon and the Baidu browser return "Google Inc." The Baidu browser doesn't seem to even tweak the UA string. The Sogou browser seems to have more users, but just downloading it has an ETA of 1 hour so I'm not testing it.

Using navigator.vendor to work around bugs in specific versions of Chromium is therefore only going to work for specifically targeted vendors and those who pretend to be Google.

If left alone, I think at best navigator.vendor will end up as the constant "Google Inc." or possibly "Apple Computer, Inc.", but at worst it'll become a source of incompatibility for new browsers, Chromium-based or otherwise.

(In reply to Philip Jägenstedt from comment #13)
> Bruno, do you have a link to a site that uses your library so that we can
> talk about concrete issues?

The above issues are concrete.

Assuming DoNotTrack shall not be trusted/supported on Firefox < 32 require detection of Firefox combined with a feature detect. I can never trust the UA if I am to account for older bugs for back compat.

Support for Dynamically updating <meta viewport> can't be done on Firefox yet. I have to set a new viewport on FF, and set it twice on Webkit to avoid zoom issues, or @viewport for IE/Presto. https://twitter.com/miketaylr/status/438382185180323840
Those are very specific behaviors along physical and device-width distinctions or needed corrections to account for screen and viewport cross-compat mess. http://www.quirksmode.org/mobile/tableViewport.html quirks.

Another similar issue for hasfocus(). It only works reliably for Chrome 30+, but works for any Safari version. If I did trust the Chrome/ token with a regex on the ua, like virtually all libraries do. I would end up assuming any Chrome 29- token which in fact may not be Chrome but AppleWebkit or QtWebkit as wrongly having a non-working hasfocus(). Given that IE now has Chrome token, you can see where that leads.

Or another case here, where incorrect prefixes on IE's part makes it impossible to detect atRules: https://github.com/Modernizr/Modernizr/pull/1132#issuecomment-49923209. Feature detection doesn't work here.

I always use feature detection first, but fallback to reliable engine check and/or features eliminations in order to guarantee that the cross-compat bug, behavior or lack of feature I am addressing is full-proof.

And by the way, all Mozilla sites currently detect Safari with navigator.vendor so does Apple, and likely many others. It's otherwise impossible, considering the Safari token is going to be on almost all user-agents now. Doing Safari/X but not Chrome/X and Not Edge/X is really a much worse future-proof code path.

I have an early implementation at http://goo.gl/v8HdLD. The "desktop mode" mobile resize should work everywhere. Please only share this link and not the site's.

(In reply to Bruno Racineux from comment #16)
> I have an early implementation at http://goo.gl/v8HdLD. The "desktop mode"
> mobile resize should work everywhere. Please only share this link and not
> the site's.

Thanks. So this is it:

> corp = this.vendor ? this.vendor.split(' ')[0] : ''

Followed by many branches based on corp, setting up a lot of information on the ua object. There's some interesting bits that tease apart Chromium-based WebView from older WebKit-based WebView, the conditions for which are so complex I'm guessing it's only reliable for already-shipped browsers and not expected to continue reliably identifying future Chromium-based WebView.

One bit of code is clearly going to break:

> if (win.chrome && !u.name && !u.agt && corp === 'Google' && (plugin.ChromePDFViewer || (u.winorient && (u.eng !== 'Android' || (win.WebkitMutationObserver && !u.webview))))) {
>     u[(u.agt = 'Chrome').toLowerCase()] = float(u.ver = t.chrome) || Inf;
> }

If Google Chrome ships with navigator.vendor "", it'll no longer be identified as Chrome by this script. But as far as I can tell changing it to (corp === 'Google' || corp === "") will work pretty well, it'll exclude existing Chromium-based browsers that tweak navigator.vendor, and extra tokens in UA string already disqualify them via u.name.

Note that the Baidu browser is currently classified as Chrome by your script. Trying to distinguish official Google Chrome from Chromium-based browsers that try to look exactly like Chrome seems incredibly hard, and hopefully unnecessary since they'll be built from largely the same code.

I'm very sympathetic to the need for working around undetectable bugs, and your script won't stop working for already shipped browsers, which are after all the only ones where specific bugs are known to exist. navigator.vendor has been useful to you, but its far from the only tool in your toolbox. *If* I get my way and there's a bug in a specific future release of Chromium that you need to detect, I'd be happy to look for a combination of Web-facing changes that would identify that particular release.

(In reply to Philip Jägenstedt from comment #15)
> I had a look at a few other Chromium-based browsers.
> 
> Cốc Cốc returns "Coc Coc". The Yandex browser returns "Yandex". These
> browsers have significant share in Vietnam and Russia respectively, and both
> also have distinguishing bits in the User-Agent string.

CocCoc's UA smells. What kind of format is "coc_coc_browser/"?
AFAIK User Agent RFC standards state that name must be normally separated
by linear "white space" not underscores. And could that be made Uppercase please.
Browser isn't needed either it's useless, we all know it's a browser.
Should be either "CocCoc/X" of "Coc Coc/X"

> Comodo Dragon and the Baidu browser return "Google Inc." The Baidu browser
> doesn't seem to even tweak the UA string. The Sogou browser seems to have
> more users, but just downloading it has an ETA of 1 hour so I'm not testing
> it.

It doesn't matter that's not way to identify Chrome in the first place. Given what you told me before is inaccurate (coming from an Opera employee you can't wonder why other devs make mistakes...)

You said: "To differentiate between WebKit-based and Chromium-based browsers, you can check if window.chrome is defined." and "There's still window.opr and OPR in the user agent string to distinguish it"

Both of your statements are incorrect. There is no window.chrome not window.opr on the android Opera Mobile version. I do detect all chrome version correctly because I rely on the initial's engine particulars. I only pick up names if not chrome for analytics data. 

That means if there was a problem on Opera only, vendor is the only go to for a vendor exception. So if you worry about Opera's cross compat, my advice would to actually add window.chrome on the mobile version. Empty vendor or not in Opera isn't gonna help anything.

> Using navigator.vendor to work around bugs in specific versions of Chromium
> is therefore only going to work for specifically targeted vendors and those
> who pretend to be Google.

Please let me do the thinking on what works and what mistake could be made.

> If left alone, I think at best navigator.vendor will end up as the constant
> "Google Inc." or possibly "Apple Computer, Inc.", but at worst it'll become
> a source of incompatibility for new browsers, Chromium-based or otherwise.

I don't see how that would make incompatibility. You have no use case. It's pure speculation.

Instead of wasting time on this. There is really better time spent on fixing bugs if you want to make a difference and "make the web a better place".

(In reply to Philip Jägenstedt from comment #17)
> I'm guessing it's only reliable for already-shipped browsers and not
> expected to continue reliably identifying future Chromium-based WebView.
Yes. Chromium is now blink which is a separate distinct branch.

> If Google Chrome ships with navigator.vendor "", it'll no longer be
> identified as Chrome by this script. But as far as I can tell changing it to
> (corp === 'Google' || corp === "") will work pretty well

Not if and 'empty' string is a spec and every Blink browsers start chnaging it too. But I'd have ways around it.

> Note that the Baidu browser is currently classified as Chrome by your script.
And that's fine. One of the very few I haven't tested.

> Trying to distinguish official Google Chrome from Chromium-based
> browsers that try to look exactly like Chrome seems incredibly hard, and
> hopefully unnecessary since they'll be built from largely the same code.

Nods, some of these things are only analytics oriented and pushing it a bit, but code wise ua.blink is the only things that matter for the engine really.

> I'm very sympathetic to the need for working around undetectable bugs, and
> your script won't stop working for already shipped browsers, which are after
> all the only ones where specific bugs are known to exist. navigator.vendor
> has been useful to you, but its far from the only tool in your toolbox.

If your erm "get your way", it become specs, Safari has to remove it. Konqueror has to remove it. UCWEB/U3 has to remove it. It's not all about Opera's interest, you affecting other forks of webkit and other engines. You use case isn't justified to me without a proper context, and I remain concerned for the future accuracy of analytics.

Nothing prevents you from doing it now, 'vendor' isn't standard. But advocating an empty string *only* as standard is bad in my opinion, unless replaced by an proper 'engine' token, which helps solve the problem on the long term.

This catch-22 policy of making everything empty just drives my "conscientious" mind insane.

(In reply to Bruno Racineux from comment #18)
> You said: "To differentiate between WebKit-based and Chromium-based
> browsers, you can check if window.chrome is defined." and "There's still
> window.opr and OPR in the user agent string to distinguish it"
> 
> Both of your statements are incorrect. There is no window.chrome not
> window.opr on the android Opera Mobile version. I do detect all chrome
> version correctly because I rely on the initial's engine particulars. I only
> pick up names if not chrome for analytics data. 

I was wrong about window.chrome and window.opr, thanks for pointing that out. I've filed an internal bug to investigate whether these should be exposed in Opera for Android.

> That means if there was a problem on Opera only, vendor is the only go to
> for a vendor exception. So if you worry about Opera's cross compat, my
> advice would to actually add window.chrome on the mobile version. Empty
> vendor or not in Opera isn't gonna help anything.

There's also OPR/* in the UA string. For small Chromium-based browsers, I think having the same navigator.vendor as Google Chrome is more important for compat than the specific content of that string. The empty string just seems like the thing most likely to resist mutation long-term.

(In reply to Bruno Racineux from comment #19)
> Nothing prevents you from doing it now, 'vendor' isn't standard. But
> advocating an empty string *only* as standard is bad in my opinion, unless
> replaced by an proper 'engine' token, which helps solve the problem on the
> long term.

I'm OK with the spec saying 'Must return either the empty string or the full name of the browser vendor, e.g. "Mellblom".' and letting "the market decide." Hixie, can you make it so?

As for a long-term solution, I can't see a new token continuing to be reliable for very long. It'll either mutate forever like navigator.userAgent or become a constant like navigator.product. It's not clear yet which category navigator.vendor will join.

I managed to download the Sogou browser now, it has navigator.vendor "Google Inc." and navigator.userAgent "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 SE 2.X MetaSr 1.0".

(In reply to Philip Jägenstedt from comment #20)
> There's also OPR/* in the UA string. For small Chromium-based browsers, I
> think having the same navigator.vendor as Google Chrome is more important
> for compat than the specific content of that string. The empty string just
> seems like the thing most likely to resist mutation long-term.

But you are the only one advocating that Chrome changes to empty. It's too late to be making that change. For IE to have done so makes sense for historical reasons, given that the new IE is vastly different from IE8 days.

There is too much code that rely on 'Google Inc.' and 7-8% usage range is too high to remove it. Off the bat, I see two explicit answers on stackoverflow with many likes and ten thousands of views that may affect you. e.g. http://stackoverflow.com/a/13348618/1647538
This is where I am not ok with it. It breaks tons of web sites.

Blink browsers that have a vendor that's not 'Google inc.' are/have 'Opera Software ASA', 'Maxthon', 'Yandex' and 'Whitehat Security Inc' (Aviator), and 'Coc Coc'.

Addressing Opera to align with all Blink browsers is good (the window.chrome missing mobile part especially), all other blink browsers have window.chrome everywhere. But please don't make Google's Chrome Browser return an empty vendor.

If you must align to avoid being in the not Chrome category. Just change Opera back to 'Google Inc.'

(In reply to Bruno Racineux from comment #23)
> But you are the only one advocating that Chrome changes to empty.

I've now sent an Intent to Implement and Ship to blink-dev:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/QrgyulnqvmE

Note that it's not a proposal to do it regardless of the outcome, but to try it and revert before it reaches stable if too much trouble is found.

This needs approval from 3 of Google's API owners, so if I'm the only one who thinks it's worthwhile it just won't happen.

> If you must align to avoid being in the not Chrome category. Just change
> Opera back to 'Google Inc.'

Yes, this is plan B. Not sure what to propose for the spec if this happens.

Comment 21 is consistent with the rest of the text in the spec and I'm fine with doing that.

My prop(In reply to Philip Jägenstedt from comment #24)
> I've now sent an Intent to Implement and Ship to blink-dev:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/QrgyulnqvmE

This failed to get the needed support, so I settled for freezing navigator.vendor as "Google Inc." in Blink by making it harder to tweak without maintaining a patch in a location where there's a comment linking to the relevant bugs and discussions:
https://codereview.chromium.org/896463002

That means we won't have interop, so if spec'd as in comment #21 that would be OK. It needs to be a string.

I would like to throw navigator.vendorSub into this bug since it also can't be removed:
https://www.chromestatus.com/metrics/feature/timeline/popularity/125

It's the empty string in every browser I tested, so no need to allow for variation there.

I've file bug 27954 for navigator.productSub.

We could say that navigator.vendor has to be "Google Inc.". What do the non-Blink browsers do here? Could they change?

I'll do vendorSub right away.

Checked in as WHATWG revision r8885.
Check-in comment: navigator.vendorSub constant
https://html5.org/tools/web-apps-tracker?from=8884&to=8885

(In reply to Ian 'Hixie' Hickson from comment #28)
> We could say that navigator.vendor has to be "Google Inc.". What do the
> non-Blink browsers do here? Could they change?

Are you talking about making Apple's webkit to have navigator.vendor "Google Inc."?
That would be detection hell AFAICT.

Microsoft may do so on their own, if that make older more chrome minded sites work in their new Edge engine. Ref: https://twitter.com/hexalys/status/571529592961441792.

But I really stress that forks of webkit should stay differentiated. UCWeb, Blackberry, KDE and possibly others have their own vendors.

> I'll do vendorSub right away.

That one was only used on Netscape and empty everywhere so that's fine, except that if
now made a spec, that mean IE/Edge has to add it... right? (IE and Presto don't have it)

(In reply to Ian 'Hixie' Hickson from comment #28)
> We could say that navigator.vendor has to be "Google Inc.". What do the
> non-Blink browsers do here? Could they change?

There are currently three strings among the four big engines: "" for Gecko and IE, "Apple Computer, Inc." for WebKit and "Google Inc." for Chromium.

I agree with Bruno that it's plausible that IE will adopt "Google Inc." to improve their Chrome camouflage, but that's really speculation.

In particular for Gecko it seems very unlikely that using "Google Inc." would improve the compat situation as they end up in the wrong code path, so I'm not hopeful.

As with the taintEnabled thing, the "wrong code path" is only wrong if there's some other differences, so I guess this is just something to do once we've removed the other differences...

Yes, revisiting these differences every 2 years or so would be a good idea. Until the incompatibilities are actually gone, however, it seems like a service to everyone involved to document them. I suppose there's the risk of people seeing the documentation and relying on the differences even more, but then these are already cases where usage is too high to change them.

https://github.com/whatwg/html/pull/78