These strings also appear in the User-Agent.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Gecko_user_agent_string_reference says 20100101 is used in desktop Firefox but not on mobile. However, navigator.productSub is 20100101 on mobile Firefox AFAICT.

I am fine with 'either'. Definitely against "empty" as specs, as I wouldn't want to loose the valuable '20030107' KHTML flag.

All Webkit based browsers and Konqueror have this '20030107' unique identifier. It represents the Apple's forking date of the KDE engine and first Beta release of Safari.

For the IE Tech Preview Edge engine to replicate that, deliberately fooling code that Explorer is a full-fledge webkit engine is dangerous distortion.
 
Implementors love to complain that browser detection is wrong. But Microsoft is playing that very same game here. IE12/Edge is trying to pass for a Webkit engine for previously written javascript code. And yet, it has none of the native specific characteristics and/or bugs of Webkit, which on would try to circumvent by being a responsible developer. I find this very troubling.

For IE to support webkit prefixes is reasonable. However, pretending to be something they are not, and deliberately messing around with good signals like this, will break "good and well intended" code. I'd welcome a 'navigator.productSub' spec prohibiting browsers from that kind of misleading practice.

Aside from webkit, navigator.productSub does little for me. Gecko's '20100101' is not fully consistent because some windows build had the Firefox build version  instead. So it can be used as a signal, but not a unique a guarantee.

And as Simon mentioned, Firefox Mobile on GeckoOS deliberately made navigator.productSub, navigator.vendor and navigator.cpu all empty. But all other desktop versions of Firefox kept their initial values. '20100101' is otherwise the mark of a Gecko 2 engine.

Would Gecko be willing to change productSub to 20030107 everywhere?

CC Boris as the usual Mozilla suspect :)

Hmm.  Gerv, do you happen to recall what issues we ran into when we tried removing productSub altogether on desktop, whether they were issues with just the UA string proper or with the specific navigator.productSub getter, and whether we'd have the same issues with the "20030107" string?

Hi Boris,

As I remember, what we did was try and replace the current date with "17.0" or "4.0" or some other Firefox version number in the UA string. However, we had the problem that people were doing numeric comparisons against particular date values to check for support for things, and because 4.0 is < 20080801 (for example), those checks were failing.

We managed to make this change on Mobile, but not on Desktop. So now our UAs are distinct in this regard. 20100101 should not be used for detecting Gecko - searching for "Gecko/" should be used for that.

None of the above directly relates to productSub, though - we were looking at it from the perspective of UA parsing.

Still, therefore, I'd say we wouldn't support changing it to a lower value (20030107), because people may still be doing numeric comparisons on the number that they expect to pass, and those may well fail unexpectedly.

Gerv

Would it likely be safe for Gecko to always return "20100101"? That would at least limit productSub to two possible values.

(In reply to Philip Jägenstedt from comment #7)
> Would it likely be safe for Gecko to always return "20100101"? That would at
> least limit productSub to two possible values.

That's what we do now, isn't it?

Gerv

(In reply to Gervase Markham from comment #8)
> (In reply to Philip Jägenstedt from comment #7)
> > Would it likely be safe for Gecko to always return "20100101"? That would at
> > least limit productSub to two possible values.
> 
> That's what we do now, isn't it?

Oh, great if so. Can you check comment #1 to see if that documentation is just wrong?

> Oh, great if so. Can you check comment #1 to see if that documentation is
> just wrong?
The doc is not wrong. But I can see that our comments are indeed confusing, as we are speaking of two different mobile(s). To clarify:

I am pretty sure Simon's observation was referring to Firefox on Android.
While both Gervase and I meant 'mobile' as in the Firefox OS (B2G Phone).

Firefox on B2G is an empty string. Firefox on Android is still "20100101".

Someone with a Firefox OS phone would need to check what navigator.productSub is. We changed the UA, but that doesn't _necessarily_ mean productSub is always the same value.

Is there a website which dumps these values to the page so we can test?

Gerv

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3405

Thank you. The answer appears to be 20100101 on both Firefox OS and Firefox for Android.

Gerv

(In reply to Gervase Markham from comment #11)
> We changed the UA, but that doesn't _necessarily_ mean productSub is always the same value.

Ok. You are right. My mistake. The B2G emulator has indeed productSub "20100101".
Gecko could be frozen at "20100101" and Webkit at "20030107". That would work.

What do we tell new UAs (like servo) to implement?

Have you decided what UA string Servo will have? I suspect this and many other questions will follow naturally from that...

I don't know that that's been decided, but the point is in an ideal world the spec would describe the interactions there instead of requiring reverse-engineering....

Yes, that is true. I'd certainly be OK with the spec saying that if the UA string contains this and that, productSub should be this and that.

Have non-Gecko browsers considered changing to "20100101"?

Since we now have three non-Gecko engines returning "20030107" it seems like a tough job to change them to something else.

An analysis of how productSub is used in the wild might make some changes seem safer than others, though. Simon, does a quick search for 20030107 and 20100101 in httparchive data reveal anything interesting?

http://storage.googleapis.com/zcorpan/20030107.csv.gz 6 matches
http://storage.googleapis.com/zcorpan/20100101.csv.gz 199 matches (~4MB file)

Because the Gecko date was originally a Gecko invention, I would suspect that it was more often checked in Gecko-detecting code paths, and so 20100101 would be a more common value to check for on the web than 20030107. In addition, if people are doing numeric comparisons, it it more compatible to round the figure up rather than down. 

As noted in comment 6, Mozilla at one point tried to replace the date with a Firefox version number, but we found that sites were doing:

if (number > 20080507) {
  // Use new Gecko feature
}

and if "number" was 15.0 or 21.0, then of course the comparison failed and we got the old codepath. That's how we ended up freezing the Gecko date at the current value at the time (or thereabouts).

So I'd say either we spec that either value is permissible, or we spec the 20100101 date. If it takes a few years for UAs to catch up, I doubt the web will be weeping into its beer.

Gerv

There was a lot of noise in the 20100101 matches. The only thing being relevant for 20100101 are matches of "<20100101" and ">=20100101", for which there are three pages.

page url
http://www.privemanagers.com/ https://www.privemanagers.com/sly/sc/modules/ISC_Core.js
http://www.songs.to/	http://songs.to/songs/sc/modules/ISC_Core.js
http://www.sourcenext.info/	http://www.sourcenext.com/js/_site.js

some extracts:

var _8=isc.Browser.geckoVersion,_9=_8<20100101&&((_5.overflow!=""visible"")&&(_8>=20051111||(_7==isc.Canvas.ABSOLUTE&&_5.overflow!=""hidden"")))

isc.D=isc._funcClasses;isc.D[isc.C]=isc.A.Class;isc.A.redrawOnResize=false;isc.A.overflow=""hidden"";isc.A.useExplicitHeight=isc.Browser.isSafari||(isc.Browser.isFirefox&&isc.Browser.isStrict&&isc.Browser.geckoVersion>=20100101);

var _8=isc.Browser.geckoVersion,_9=_8<20100101&&((_5.overflow!=""visible"")&&(_8>=20051111||(_7==isc.Canvas.ABSOLUTE&&_5.overflow!=""hidden"")))

var _9=isc.Browser.geckoVersion;var _10=_9<20100101&&((_6.overflow!=""visible"")&&(_9>=20051111||(_8==isc.Canvas.ABSOLUTE&&_6.overflow!=""hidden"")))

isc.A.useExplicitHeight=isc.Browser.isSafari||(isc.Browser.isFirefox&&isc.Browser.isStrict&&isc.Browser.geckoVersion>=20100101);


(This does not take into account comparing other values as Gerv said above pages are doing.)

For 20030107, three pages.

page url
http://www.javaworld.com.tw/	http://www.javaworld.com.tw/jute/javaworld/home.js
http://www.trashbox.ru/	http://trashbox.ru/webcache/all1201407055542.gz.js
http://www.dell4me.com/	http://www1-cdn.dell.com/JS/default/jsmin.ashx?set=masthead&theme=default&cmp=0&version=14.7.31.1

if( suppressMenus || ( isOpera && readOperaVer() < 7 ) || ( isGecko && navigator.productSub <= 20011022 ) || ( isGecko && navigator.productSub == 20030107 ) ) { // Opera 6.x doesn't seem to like the DHTML... // Netscape 6.2 puts the menus in the wrong place... // Safari, the menus don't go away... problem in ResetMenu isDHTML = false; } } }

if(navigator.product==""Gecko""&&navigator.productSub>=20030107&&!(typeof(opera)=='object'&&opera.postError)){this.gecko=true;return true;}

if (isGecko && navigator.productSub == 20030107) { var x = navigator.userAgent.indexOf(""AppleWebKit""); if (x > -1) { isDHTML = (navigator.userAgent.substring(x + 12, x + 15)) > 300; } else { isDHTML = false; }

Interesting, not a single case of `if (isWebKit && navigator.productSub=="20030107") doStuffWithPrefixes();` or `var WebKit = navigator.productSub=="20030107"`?

Nope

That's a bit surprising, but encouraging. It still seems like a formidable challenge to have Blink, WebKit and IE change, though. If we can get people from WebKit and IE saying that they'd consider trying it, maybe.

Spec'd in https://github.com/whatwg/html/pull/199