588909 - Replace Gecko/<date> with Gecko/<version> in UA string

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect)

Description

[[e-mail]]

If we remove build date (bug 572661), then we're ripe to put the major version there instead. Doing so will minimally affect sniffer compatibility (sniffing for the year *should* be rare) -- we'd break people that sniff for a particular build ID.

Comment 1

[rsx11m]

This also depends on bug 572659 (i.e., if won't-fixed, the string behind Gecko should represent the full version information, not just the major rev).

Comment 2

[Benjamin Smedberg]

I've seen sites that sniff for "dates after N". If we need to keep Gecko/anything for compatibility, I think we should freeze a date-looking thing (adding HHMM to the date broke site compatibility). Or we should just say Gecko or Gecko/

Comment 3

[rsx11m]

> (comment #2) should freeze a date-looking thing

That was already part of the discussion in bug 572661. I think the purpose
of this specific bug here should be rather narrow to avoid replicating or bypassing any discussions taking place in the other bugs...

Comment 4

[[e-mail]]

(In reply to comment #2)
> I've seen sites that sniff for "dates after N".

Any idea how many, roughly?

Comment 5

[Benjamin Smedberg]

No, I just know we truncated the UA string date to avoid problems.

Comment 6

[Dave Garrett]

The implication of this bug would to go from:
Mozilla/5.0 (X11; Linux i686; rv:2.0b4) Gecko/20100818 Firefox/4.0b4
to:
Mozilla/5.0 (X11; Linux i686) Gecko/2.0b4 Firefox/4.0b4

I generally like this idea, but the removal of the "rv:" would break some sniffers. Go to geckoisgecko.com and see the "correct" way to sniff the Gecko version and it is using the position of "rv:" to find the Gecko version. One hack I saw mentioned elsewhere in this maze of bugs on these topics was to do:

Mozilla/5.0 (X11; Linux i686) Gecko/rv:2.0b4 Firefox/4.0b4

which while ugly, would break fewer sniffers. Personally, I'd just drop the "rv:" and let 'em break, but that's just me.

Comment 7

[[e-mail]]

Unconflating summary. Dropping minor version from the Gecko bits is bug 572659.

Let's make this bug about moving the 'rv:' value to Gecko/.

Comment 8

[Matthias Versen [:Matti]]

Yahoo used the year in the past (2009:bug 471816, 2008:bug bug 410430)

Comment 9

[[e-mail]]

Yeah, that's come up a few times. They keep breaking every year, too. We'll be doing them a favor by dropping the year.

Comment 10

[[e-mail]]

Attachment: patch

Copy the 'rv:' value to Gecko/. UA looks like:

Gecko/2.0b5pre (X11; Linux x86_64; rv:2.0b5pre) Minefield/4.0b5pre

Comment 11

[[e-mail]]

Now that I think about it, I kinda agree with comment 2; we should just have 'Gecko' and leave 'rv:' alone.

Leaving the patch up for comment.

Comment 12

[Dave Garrett]

(In reply to comment #11)
> Now that I think about it, I kinda agree with comment 2; we should just have
> 'Gecko' and leave 'rv:' alone.

As in this? (including "Mozilla/5.0" drop and "Gecko" move)

Gecko (X11; Linux x86_64; rv:2.0b5pre) Minefield/4.0b5pre

Comment 13

[[e-mail]]

Yes.

Comment 14

[Ben Bucksch (:BenB)]

dwitte, your patch is in line with comment 2: It would have both the correct (per RFC) "Gecko/2.0b5pre" as well as "rv:2.0b5pre".
I'm not proposing that, though - I'd go for just "Gecko/2.0 (Linux i686)".

Having only "Gecko" or "Gecko/" is really bad - the former is indistinguishable from WebKit and forces people to continue looking for "rv:", if they want Gecko. The latter is just invalid.

Comment 15

[[e-mail]]

The problem with 'Gecko/2.0b5pre' is that it looks similar to 'Gecko/20100523', but the interpretation of the field has changed. That's risky. I suppose you could argue that a sniffer expecting the year will break if it doesn't exist, too...

Regarding WebKit, if they want to pretend to be Gecko, that's their problem. They're better off guarding on the absence of 'WebKit' in the string.

Comment 16

[Masatoshi Kimura [:emk]]

Japanese community recommended to search the string "Gecko/".
http://www.mozilla.gr.jp/standards/webtips1005.html#c1_3
Do we have to change our document?

Comment 17

[rsx11m]

I wouldn't be surprised if "Gecko/" is more frequently looked for, given that it distinguishes Mozilla browsers from those just adding "like Gecko" to their UA.

Re comment #15, assuming an integer is interpreted as the date, a sniffer would find a date of "2" for "Gecko/2.0b5pre", thus most likely reporting an outdated browser if that's the (stupid) way how it checks it.

Comment 18

[Dave Garrett]

On the topic of doing "Gecko/rv:ver": actually, the script on geckoisgecko.com expects the version to start with "rv:" and end with ")" so the sniffer compatibility keeping form would be:
Mozilla/5.0 (X11; Linux i686; Gecko/rv:2.0b4) Firefox/4.0b4
not what I said in comment 6.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #16)
> Japanese community recommended to search the string "Gecko/".
> http://www.mozilla.gr.jp/standards/webtips1005.html#c1_3
> Do we have to change our document?

Unfortunately, I cannot update the document because I'm not a member of Mozilla-gumi. I'm not sure whether they will update it even though I tell that.

Comment 20

[[e-mail]]

Not gonna do this.

Comment 21

[Ben Bucksch (:BenB)]

> Not gonna do this.

Please give reasons and who decided that.

Specifically, given that you fix bug 572661, that doesn't make any sense to me. See comment 14.

Comment 22

[[e-mail]]

The rationale here was that we're not dropping the 'rv:' token, because it's been the recommended way of sniffing for Gecko-proper browsers, along with "Gecko/", and is doubtless used all over the place. Given that, there's no point in duplicating information. It's purely an aesthetic argument. (Dropping the build ID is a separate issue and shouldn't be conflated with having the Gecko version appear here.)

If we ever delete the 'rv:' token, then this can be revisited. Putting major version there right now doesn't really buy us anything, because existing sniffers will continue to use 'rv:' while it exists.

Comment 23

[Ben Bucksch (:BenB)]

Dan, you write in
<http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/>:

> The build date will be dropped entirely in the next major release, making the > token just “Gecko” without the “/” or the date. (The build date itself has
> always been misleading — it’s not related to the Gecko version in any
> meaningful way.) This means:

Safari also says "Gecko", so I don't see why we should change to just " Gecko ". It will just cause people to look for "Firefox" (see below).

>  If you’re using this token to distinguish real Gecko from “like Gecko” 
> browsers, you should search for “Gecko” and “rv:”. Do not rely on the fact
> that “Gecko” will be followed by a “/” and a string of digits.
> You will break if you do this.

I don't think this is a good recommendation. This recommendation prevents us from ever fixing this bug. The standard clearly says "Gecko/2.0" is the correct way, so that's the eventual direction we should take. If we need to keep the rv:2.0 for compat for a while, so be it, but the goal must be to do what the standard suggests.

You're recommending sniffers to do the exact opposite. If you already recommend to change sniffers, then please recommend them to look for "Gecko/", so that we can change to "Gecko/2.1 (rv:2.1)" later, and eventually "Gecko/2.1".

> If you need to compare against a specific minor version, use the
> Gecko version (“rv:x.y.z”) or the Firefox version (“Firefox/x.y.z”).

Please strongly discourage people from looking for "Firefox" *at all*. This just perpetuates further UA string insanity. Firefox vs. Beonex is irrelevant, what's relevant is Gecko only.

Comment 24

[Dão Gottwald [:dao]]

Fennec is now using Gecko/<version> after doing some research with the result that this seems to have no significant impact on compatibility (<https://wiki.mozilla.org/Fennec/User_Agent>). The rest of the mozilla platform should follow this for consistency.

(In reply to Dan Witte (:dwitte) (not reading bugmail, email to contact) from comment #22)
> If we ever delete the 'rv:' token, then this can be revisited. Putting major
> version there right now doesn't really buy us anything, because existing
> sniffers will continue to use 'rv:' while it exists.

This is backwards. Once we have Gecko/<version>, we can advocate for that, freeze rv: at some later time and eventually remove it. We can't do any of this without Gecko/<version>.

Comment 26

[Dão Gottwald [:dao]]

Attachment: patch

r?bz since this is mostly networking code, sr?gerv since I'm told he's the de-facto UA string module owner. Maybe it should be the other way around since bz is a super-reviewer...

Comment 27

[Robert Kaiser]

I'm all for this, and would cheer extensively for this step.

Still, Asa seemed to imply on dev.platform that the product team for Firefox maybe should be involved in getting this to desktop Firefox, and that we should do more extensive research as to what impact it has on the general web (the research that has been done for the Fennec change affected major mobile sites, AFAIK, so a different sample).

That said, I think it would be fitting to do this change now at the start of the 13 cycle on trunk and crowdsource our research of problems, doing a tracking bug about any sites that run into problems due to this, and then we can revisit this when 13 is on Aurora (or even Beta) and see if we need to back out or can leave it in.

Comment 28

[Daniel C]

I'm for this change. Bear in mind though that bug 651674 still exists. As my homepage is google.co.uk this is a bit annoying but looking at bug 651674 comment 21 it seems like Google won't actually change anything until Mozilla has committed to the new user-agent string. Therefore its probably best to land this and then say to Google "your site breaks in Fx nightly (to become Fx 13), please stop sniffing for a date after the Gecko/ string.". Pull any Google strings that are necessary.

Comment 29

[Robert Kaiser]

(In reply to Daniel Cater from comment #28)
> Therefore its probably best to
> land this and then say to Google "your site breaks in Fx nightly (to become
> Fx 13), please stop sniffing for a date after the Gecko/ string.". Pull any
> Google strings that are necessary.

Actually, due to this already having been done for mobile, I think we can start pulling strings right now. But as I said in comment #27, I agree that we should land on trunk and see where we run into problems - probably also have someone assigned to do specific QA on this somewhere in this cycle. It's easy to back this out in Aurora (or even in Beta if needed) when things look too bad.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 593346 [details] [diff] [review]
patch

r=me

Comment 31

[Dão Gottwald [:dao]]

CC'ing John Jensen who did the research in bug 690287. Maybe he can help out here as well?

Comment 32

[John Jensen]

Happy to help; all I need is CRLF-separated list of UAs to test, with at least one "reference" UA to which you want to compare all the others.

Comment 33

[Dão Gottwald [:dao]]

(In reply to John Jensen from comment #32)
> Happy to help; all I need is CRLF-separated list of UAs to test, with at
> least one "reference" UA to which you want to compare all the others.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/13.0 Firefox/13.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/13 Firefox/13.0

The first one is the reference. Thanks!

Comment 34

[Ben Bucksch (:BenB)]

One more alternative, if it's for free:
Mozilla/5.0 (Windows NT 6.1; WOW64) Gecko/13 Firefox/13.0

Comment 35

[Gervase Markham [:gerv]]

Ben: better to change only one thing from the reference string. So I would use instead:

Mozilla/5.0 (Windows NT 6.1; WOW64) Gecko/20100101 Firefox/13.0

I am pleased that there is movement here but, having stood up and argued for data-driven decisions, I am not going to sr= this patch without data. :-)

John: what we are looking for in this test is any difference in the page other than irrelevant differences like ads ;-) I realise that's an impossible ask, but I hope you can come up with some approximation.

Gerv

Comment 36

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Gervase Markham [:gerv] from comment #35)
> Ben: better to change only one thing from the reference string. So I would
> use instead:
> 
> Mozilla/5.0 (Windows NT 6.1; WOW64) Gecko/20100101 Firefox/13.0
> 
> I am pleased that there is movement here but, having stood up and argued for
> data-driven decisions, I am not going to sr= this patch without data. :-)

AIUI, the goal of this bug is first and foremost to determine the feasibility of changing "Gecko/20100101" to "Gecko/13" or "Gecko/13.0". This would result in redundant data about the Gecko version number. In addition, the GeckoIsGecko guideline suggests searching for "rv:" to determine Gecko version. So, Ben's suggestion of removing the "rv:" data alongside the "Gecko/13" change is to doubly determine what would break, and to see if it would be feasible to make both changes at once. I don't see the benefit of testing a UA string without the "rv:" data if it still includes the frozen Gecko build date.

Comment 37

[Ben Bucksch (:BenB)]

I didn't mean to suggest that we remove the "rv:" now in this bug. I said "If it's for free" to test it. I was just curious. Nevermind.

Comment 38

[rsx11m]

(In reply to Dão Gottwald [:dao] from comment #33)
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/13 Firefox/13.0

What is the rationale of having a different granularity for the Gecko string compared to the application version? If in the long run the "rv:" part would go away (which is bug 588913) the Gecko/* number is the only authoritative field specifying that version.

Also, the "dot" would help UA parsern to distinguish between date and version, if they are still using that token for anything at this time.

Comment 39

[Ben Bucksch (:BenB)]

> What is the rationale

Rationale in bug 572659

Comment 40

[Ben Bucksch (:BenB)]

(i.e. no need to *introduce* something that could be problematic.)

Comment 41

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Ben Bucksch (:BenB) from comment #37)
> I didn't mean to suggest that we remove the "rv:" now in this bug. I said
> "If it's for free" to test it. I was just curious. Nevermind.

True. Sorry I made that implication.

I should have differentiated between collecting data on an issue and actually making the change. Naturally, removing the "rv:" from the UA string would be a separate bug. (And, actually, it was: bug 588913. I imagine that WONTFIX decision would have to be revisited, depending on the data.)

I see no reason to not proceed with the data collection for everything. I imagine it would be easier to collect all data at once, and to make all changes in a single version of Firefox, assuming the data would allow for it. (That is, better to collect the data now and have it show that it wouldn't be feasible than to speculate wildly until some point in the future.)

(In reply to rsx11m from comment #38)
> (In reply to Dão Gottwald [:dao] from comment #33)
> > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/13 Firefox/13.0
> 
> What is the rationale of having a different granularity for the Gecko string
> compared to the application version? If in the long run the "rv:" part would
> go away (which is bug 588913) the Gecko/* number is the only authoritative
> field specifying that version.

It is my understanding that some people believe that there should be no way to determine among the different point releases of "major" Gecko version. At this point, the only time a point release would happen is for a firedrill release, which is usually to fix a security problem. It is not a desired behavior to indicate that a user is browsing with a vulnerable version.

> Also, the "dot" would help UA parsern to distinguish between date and
> version, if they are still using that token for anything at this time.

While I agree with this at face value, there is little additional benefit — the number that comes after the dot is "0" 99.999% of the time. Releases are pretty much always x.0(.y) format nowadays.

Comment 42

[Robert Kaiser]

(In reply to rsx11m from comment #38)
> What is the rationale of having a different granularity for the Gecko string
> compared to the application version?

Also, the patch here doesn't do that, this is just to have testing run that shows if it even makes a difference to having the full version right now.

Comment 43

[rsx11m]

(In reply to Gordon P. Hemsley [:gphemsley] from comment #41)
> I see no reason to not proceed with the data collection for everything.

KaiRo, Gordon - thanks for your responses. Yes, I see that the patch doesn't touch the current format, so my comment was rather preemptive to avoid that people are jumping on the train and trying to push further changes that were advocated in other bugs. I realize that some WONTFIXes will be revisited, but that discussion should be in those respective bugs and not injected here.

> At this point, the only time a point release would happen is for a firedrill
> release, which is usually to fix a security problem. It is not a desired
> behavior to indicate that a user is browsing with a vulnerable version.

Not exactly, the new ESR branches should have at least eight "dot" releases.

> Releases are pretty much always x.0(.y) format nowadays.

As far as Firefox is concerned, yes. This format doesn't apply though to other Gecko-based applications which maintain their own version-numbering scheme.

Comment 44

[Gordon P. Hemsley [:GPHemsley]]

(In reply to rsx11m from comment #43)
> (In reply to Gordon P. Hemsley [:gphemsley] from comment #41)
> > I see no reason to not proceed with the data collection for everything.
> 
> KaiRo, Gordon - thanks for your responses. Yes, I see that the patch doesn't
> touch the current format, so my comment was rather preemptive to avoid that
> people are jumping on the train and trying to push further changes that were
> advocated in other bugs. I realize that some WONTFIXes will be revisited,
> but that discussion should be in those respective bugs and not injected here.

Good point.

> > At this point, the only time a point release would happen is for a firedrill
> > release, which is usually to fix a security problem. It is not a desired
> > behavior to indicate that a user is browsing with a vulnerable version.
> 
> Not exactly, the new ESR branches should have at least eight "dot" releases.

Ah, yes, I'd forgotten about that.

> > Releases are pretty much always x.0(.y) format nowadays.
> 
> As far as Firefox is concerned, yes. This format doesn't apply though to
> other Gecko-based applications which maintain their own version-numbering
> scheme.

Yeah, each application has its own version numbering scheme, but there is only a single Gecko version numbering scheme, right? I was meant to refer specifically to Gecko releases (although those tend to pattern with Firefox release, so I may have been conflating them in my head). This bug is not changing any product/application version numbering scheme (as whole or as represented in the UA string), other than the representation of the Gecko engine (major) version in the UA string.

Comment 45

[John Jensen]

(In reply to Ben Bucksch (:BenB) from comment #34)
> One more alternative, if it's for free:
> Mozilla/5.0 (Windows NT 6.1; WOW64) Gecko/13 Firefox/13.0

It's free. I'll start this shortly.

Comment 46

[John Jensen]

Attachment: ODS spreadsheet summarizing comparisons with 3 proposed UA varations x 1000 sites

Hi all,

Please find attached an OpenDocument format spreadsheet summarizing the results of testing three proposed UAs with the current UA against the home pages of the global top 1000 websites. I tried repeatedly to upload it to Google Docs but it was rejected.

The methodology is the same as was employed in some of the Fennec UA discussions -- see http://markmail.org/message/txidjjt3devp5g2f.

Overall, there are some differences. Sites that presented markedly different HTML to some UAs are highlighted in yellow in the spreadsheet.

Comment 47

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

According to GeckoIsGecko shouldn't we use sth like this
Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:13) Firefox/13

compared to how it's now
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0a1) Gecko/20120204 Firefox/13.0a1

This won't break any sniffers that look property for Gecko in "rv:" value and leave the Gecko name in User-Agent string

Also you can look on other mentioned UA modifications in this bug
https://bugzilla.mozilla.org/show_bug.cgi?id=651503#c8

Comment 48

[Gordon P. Hemsley [:GPHemsley]]

According to the definition in the spec, the User-Agent field "can contain multiple product tokens (section 3.8) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application."

Section 3.8 defines a product token as follows:
"Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields using product tokens also allow sub-products which form a significant part of the application to be listed, separated by white space. By convention, the products are listed in order of their significance for identifying the application."

All the stuff in parentheses is a comment, which means it technically has no significance with regard to version numbering. That's why the goal here is to eventually obsolete the current GeckoIsGecko recommendation and move the engine data to a product token. Converging upon "Gecko/rv:13" inside a comment is, at least IMO, not the right direction to go in.

Thus, I believe the goal is to have something like this:
- "Mozilla/5.0" (because everybody has that; it essentially means "somewhat-modern browser")
- platform data in a comment (which I think should be a little more standardized at some point)
- Gecko version in a product token
- application version in a product token

No product version-related information should be in the comment, when all is said and done.

Comment 49

[Dão Gottwald [:dao]]

Comment on attachment 593973 [details]
ODS spreadsheet summarizing comparisons with 3 proposed UA varations x 1000 sites

So, we could file bugs on the affected sites and try to evangelize them before landing this. However, most incompatibilities we could hit here are likely problematic for Fennec as well, which is determined to ship Gecko/<version>. Thus I think we should join forces and be as fast and effective as possible, which means to build up pressure by deploying this to our desktop users (nightly, aurora, beta, finally release).

Gerv?

Comment 50

[Robert Kaiser]

(In reply to John Jensen from comment #46)
> Created attachment 593973 [details]
> ODS spreadsheet summarizing comparisons with 3 proposed UA varations x 1000
> sites

What's really interesting to me there is that removing the rv: comment is less harmful than reducing the Gecko token to the major version without a dot in it.

> Overall, there are some differences. Sites that presented markedly different
> HTML to some UAs are highlighted in yellow in the spreadsheet.

What's with the yellow boxes without content? Sites that completely break down?

Comment 51

[John Jensen]

> What's with the yellow boxes without content? Sites that completely break down?

Yes, sites that, at least when my test ran, did not return content. It could have been network trouble or something else. I'd recommend treating them as "worthy of closer review".

Comment 52

[Gervase Markham [:gerv]]

(In reply to Robert Kaiser (:[e-mail]) from comment #50)
> What's really interesting to me there is that removing the rv: comment is
> less harmful than reducing the Gecko token to the major version without a
> dot in it.

Not necessarily so; in order to say that, you'd need a data set where rv: was removed _without_ reducing the Gecko token to a major version. But we don't have that.

There are 16 yellow-boxed sites out of 1000 in the first column (which is about the Gecko date change, which is what this bug is about and what Mobile is now committed to). That seems a small enough number to check this in on Nightly, at least, and proceed with further checking and possible evangelism of those 16. 

I would love it if someone CCed on this bug would take on the task of looking at those 16 sites. I would anticipate it would be a couple of hours work to produce a report on which are false positives and which are broken, and file bugs on the broken ones.

Anyone? :-)

Gerv

Comment 53

[Gervase Markham [:gerv]]

Comment on attachment 593346 [details] [diff] [review]
patch

sr=gerv.

Gerv

Comment 54

[Dão Gottwald [:dao]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/bfc937247f3c

Comment 55

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/bfc937247f3c

Comment 56

[j.j.]

I hope there are plans to promote this!?

Comment 57

[rsx11m]

Certainly the recommendations for UA-string sniffing would need to be updated.
That's what I came up with thus far to figure out where to get rv/date from:

 1. Find the "Gecko/" token
 2. if the subtoken contains a dot, that's the Gecko version, and get the date
    from navigator.buildID
 3. if the subtoken doesn't contain a dot, it /may/ be the build date and you
    should look for the "rv:" string first to get the Gecko version
 4. if the rv:x.x version is <2.0, the "Gecko/" token contains the build date
 5. if the rv:x.x version is >=2.0, use navigator.buildID for the build date

Comment 59

[Masatoshi Kimura [:emk]]

(In reply to rsx11m from comment #57)
>  2. if the subtoken contains a dot, that's the Gecko version, and get the
> date
>     from navigator.buildID
>  3. if the subtoken doesn't contain a dot, it /may/ be the build date and you
>     should look for the "rv:" string first to get the Gecko version
Is this guaranteed in the future?

Comment 60

[rsx11m]

What guarantee do your expect? It's just something that seems to work for now with the current UA variants, use at your own risk without any warranties...  ;-)

Comment 61

[Robert Kaiser]

I find it actually safer to use "if the length of the 'version' part of the Gecko/ token is at least 8 characters, it's a build ID" - 8 characters is the length of a date alone, in reality we always included hours, so we always had 10 characters or more, but a conventional version will very probably never be 8 characters or more.

Comment 62

[Justin Dolske [:Dolske]]

So, this landing regressed Google, and completely broke Zimbra.

Who's backing this out? Me?

Comment 63

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Justin Dolske [:Dolske] from comment #62)
> So, this landing regressed Google

Well, I don't have an answer to your question, but we knew well in advance (bug 651674, etc.) that the change was going to regress Google.

Comment 64

[Paul [pwd]]

(In reply to Justin Dolske [:Dolske] from comment #62)
> So, this landing regressed Google, and completely broke Zimbra.
> 
> Who's backing this out? Me?

Evangelism was brought up, is that out of the question? The alternative seems to be avoiding historic changes which doesn't really seem like an alternative.

Comment 65

[Asa Dotzler [:asa]]

(In reply to Justin Dolske [:Dolske] from comment #62)
> So, this landing regressed Google, and completely broke Zimbra.
> 
> Who's backing this out? Me?

Yes, please. We're not in a position to break users for moral victories.

Comment 66

[Ed Morley [:emorley]]

> Who's backing this out? Me?

I'd be more inclined to leave it in for at least a few weeks (we can always just back out on aurora), see what falls out/file tech evang bugs accordingly, and at least we'll then have a list of sites to hassle between now and whenever this finally sticks.

Comment 67

[Daniel C]

I'd like to point out the dependencies of bug 690287 to show how many sites fix their broken sniffing once they've been notified. Evangelism can work and has worked on many occasions in Mozilla's history.

It was known before this bug was fixed that it would break Google (Fennec fixing this bug first and encountering these issues, and bug 651674 which I filed 10 months ago). In that bug Henri says: "The communication faded out when we didn't have a definitive target string plan" which suggests that with the string now actually in use Google will be much more open to fixing their sniffing (which is broken regardless of this change).

This bug has 2 open dependencies for Google and Zimbra, both of whom are active, technologically adept and have good ties with Mozilla. I would be astounded if they didn't fix things before their sniffing before this hits Beta, if not Aurora.

Comment 68

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The problem with Zimbra is not going to be getting them to fix it, it's going to be getting all of the Zimbra installations updated :-/

Comment 69

[Ed Morley [:emorley]]

Also, given that this just brings the desktop UA in line with the new Fennec UA; if this is backed out, it gives sites using broken sniffing much less incentive to update to support native UI Fennec, than if it's needed for desktop as well.

Comment 70

[Robert Kaiser]

I'm all for backing this out on Aurora if sites don't fix this within a few weeks, and even on Nightly when it takes months. But I think backing out from Nightly right now would be wrong, because if we never change our UA if sites like Google or systems like Zimbra can't break for a short time an only get updated after a bit.
I'm fully with Asa that we shouldn't expose release or even Beta audiences to this kind of breakage, but we need to be able to try things like that on Nightly for a short period.

Comment 71

[Justin Dolske [:Dolske]]

First, point of clarity (since some people have been confused):

Until this patch, the Firefox Release and Beta channels had a frozen "Gecko/20100101" [sic] string (bug 591537), whereas Aurora and Nightly were still using a string with the actual build date. AIUI, that was done so support and nightly fans could easily check what version they're running (especially in the past when the UA was prominently shown in the About dialog).

Ignoring this bug (588909) for a second, I would suggest that there are two obvious and hopefully non-controversial actions that could be taken:

1) Show the build date for Nightly/Aurora in about:support, about:buildconfig, or whatever. Seems the UA is less useful and prominent for such support roles, so let's try to fill that need independently to remove the issue from the table.

2) Make the UA for Nightly and Aurora contain the frozen "Gecko/20100101" string just like Beta and Release already do. It's good to be consistent with what ultimately ships.

This is all fodder for a DIFFERENT bug. Or outright moot, if we get this bug sorted out quickly.

I've filed bug 728773, please take any followup discussion of using "Gecko/20100101" on Nightly/Aurora there.

Comment 72

[Justin Dolske [:Dolske]]

(In reply to Robert Kaiser (:[e-mail]) from comment #70)
> I'm all for backing this out on Aurora if sites don't fix this within a few
> weeks, and even on Nightly when it takes months.

Having a broken Nightly experience for "months" on top-tier sites is not an option, just as it's not an option for any other bug that's identified as causing breakage.

If this bug has to land and bounce a few times (upon discovering further breakage), that's fine. Wouldn't be the first patch to do so. Though it probably has the least obvious end-user value.

Comment 73

[Dão Gottwald [:dao]]

The problem I see with zimbra right now is that it's used at Mozilla, so it may become a dogfooding issue -- assuming that some people actually use the web interface.

I'm not worried about Google, as it's not so badly broken that it needs to be fixed immediately in Nightly.

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #68)
> The problem with Zimbra is not going to be getting them to fix it, it's
> going to be getting all of the Zimbra installations updated :-/

Quite right... we could deal with this by switching to Gecko/13, which doesn't break zimbra.

(In reply to Justin Dolske [:Dolske] from comment #71)
> 1) Show the build date for Nightly/Aurora in about:support,
> about:buildconfig, or whatever. Seems the UA is less useful and prominent
> for such support roles, so let's try to fill that need independently to
> remove the issue from the table.

Bug 600569 was fixed long ago.

Comment 74

[Dão Gottwald [:dao]]

(In reply to Dão Gottwald [:dao] from comment #73)
> (In reply to Kyle Huey [:khuey] ([e-mail]) from comment #68)
> > The problem with Zimbra is not going to be getting them to fix it, it's
> > going to be getting all of the Zimbra installations updated :-/
> 
> Quite right... we could deal with this by switching to Gecko/13, which
> doesn't break zimbra.

This wasn't quite right, apparently zimbra can handle Gecko/13.0. So let's just fix bug 728797 for now.

Comment 75

[Gervase Markham [:gerv]]

John Jensen: do you know why your analysis did not show the Google breakage? The spreadsheet seems to suggest that google.com is almost identical when switching to Gecko/13.0. (It seems to differ a lot more for Gecko/13.) Is it because the broken and not-broken versions are actually nearly identical? Or is there some change that your diff misses?

Gerv

Comment 76

[Boris Zbarsky [:bzbarsky]]

Is the spreadsheet based on bits on wire (i.e. server-side UA sniffing) while Google is doing client-side sniffing in script?

Comment 77

[rsx11m]

Given that the revised user-agent string also goes out with e-mails sent using Thunderbird and SeaMonkey, mail/news is affected by this change as well.

For SpamAssassin, this now triggers the RATWARE_GECKO_BUILD rule which expects a date in a given range, thus increasing the spam score when sent from trunk.

This also applies to Gecko/13.0 and Gecko/13 variants.

Comment 78

[Gervase Markham [:gerv]]

rsx11m: could you please file an evangelism bug for the SpamAssassin thing? I'm fairly sure they have rule auto-update, so it shouldn't be a problem to push out a fix.

Gerv

Comment 79

[rsx11m]

Done, that's bug 728856.

Comment 80

[John Jensen]

Gerv, Boris: Not sure why this occurred; remember the data was collected some months ago and Google may have changed their UA-handling. Also remember that it is just comparing the raw HTML and is not handling client-side Javascript or comparing screenshots etc, so it could be that the difference was not that substantial.

Comment 81

[Boris Zbarsky [:bzbarsky]]

Yeah, the raw HTML in this case is just a <script> tag.  All the UA sniffing and content generation are then done by the script.

Comment 82

[Daniel C]

(In reply to Gervase Markham [:gerv] from comment #75)
> John Jensen: do you know why your analysis did not show the Google breakage?
> The spreadsheet seems to suggest that google.com is almost identical when
> switching to Gecko/13.0. (It seems to differ a lot more for Gecko/13.) Is it
> because the broken and not-broken versions are actually nearly identical? Or
> is there some change that your diff misses?
> 
> Gerv

Note that Google also often does location-based redirects. For example, when I filed bug 651674, loading google.com redirected to google.co.uk and showed the badly-rendered page. However, clicking "Go to google.com" forced the .com version to be displayed, which didn't show the errors.

So if the script just loads a URL and automatically follows redirects, it's possible that you'll end up on a different page.

Comment 83

[Daniel C]

(In reply to Justin Dolske [:Dolske] from comment #71)
> 1) Show the build date for Nightly/Aurora in about:support,
> about:buildconfig, or whatever. Seems the UA is less useful and prominent
> for such support roles, so let's try to fill that need independently to
> remove the issue from the table.

That's bug 589444, and yes, it would be useful for people filing bugs if that could be fixed as the UA is now no longer enough to identify a particular nightly.

Comment 84

[Justin Dolske [:Dolske]]

Backed out this (and bug 572659).

http://hg.mozilla.org/mozilla-central/rev/f7ccbfd0b7c6
http://hg.mozilla.org/mozilla-central/rev/d07998fb3530

Here's what I think needs to happen before relanding:

1) Use contacts at Google and Zimbra to fix problems on their end and estimate time to widely deploy. (Zimbra is of lesser importance if bug 572659 is an acceptable workaround).

2) Get to a shared understanding with Firefox module owner/peers (that's me!) and product / release drivers regarding:
  * What the cost of this change is (ie, what breaks)
  * What the benefit of this change is (ergo, can discuss cost/benefit)
  * Plan and action for disabling on aurora/beta/release, and when we expect to
    be able to leave it on through release.

I don't really care what the UA contains, but I care very much about having sudden, unexpected breakage of major web sites.

Comment 85

[Dão Gottwald [:dao]]

Dolske, Zimbra has been fixed (I have no idea why you're implying the workaround might be unacceptable), Google was known to be affected, pinged long before and again now that the code was live. I don't see why this can't remain on mozilla-central *to get a better sense of what breaks*, evangelize, and back it out from aurora or beta if we think it breaks too many things for the respective audience (same plan of action as for any other change).

Comment 86

[Justin Dolske [:Dolske]]

Actually, I do have one question about this change. Mostly curiosity, despite my better judgement, but now that I'm here...

This bug started out about moving the "rv" to the Gecko/ string (see comment 6), but mutated into just adding the version to the Gecko/ string. (Presumably because moving the "rv" had too much impact? Not clear to me.)

What's the value in changing the frozen "Gecko/20100101" to an unfrozen "Gecko/13.0" string, especially when the "rv" remains? Seems like that will just encourage more sites to start parsing this part of the UA (now that it has useful-though-redundant data) which counter to the general trend of UA changes.

Why not just "Gecko/X" (for your favorite random value of X)? Or do nothing beyond the frozen date (since it seems unlikely "Gecko/" will ever be removed)?

I guess this is just a specific flavor of #2 in my previous comment. Who benefits from this change? I'm honestly confused.

Comment 87

[Dão Gottwald [:dao]]

(In reply to Justin Dolske [:Dolske] from comment #86)
> This bug started out about moving the "rv" to the Gecko/ string (see comment
> 6), but mutated into just adding the version to the Gecko/ string.
> (Presumably because moving the "rv" had too much impact? Not clear to me.)

Once we shipped this, I will file a bug on freezing rv in order to remove it at some point.

> Why not just "Gecko/X" (for your favorite random value of X)? Or do nothing
> beyond the frozen date (since it seems unlikely "Gecko/" will ever be
> removed)?

See bug 728797 comment 4, bug 728797 comment 5.

Comment 88

[Dão Gottwald [:dao]]

> > Why not just "Gecko/X" (for your favorite random value of X)?

Err, I actually don't understand this question -- disregard my response.

Comment 89

[Dão Gottwald [:dao]]

(In reply to Dão Gottwald [:dao] from comment #87)
> (In reply to Justin Dolske [:Dolske] from comment #86)
> > This bug started out about moving the "rv" to the Gecko/ string (see comment
> > 6), but mutated into just adding the version to the Gecko/ string.
> > (Presumably because moving the "rv" had too much impact? Not clear to me.)
> 
> Once we shipped this, I will file a bug on freezing rv in order to remove it
> at some point.

(comment 24)

Comment 90

[Asa Dotzler [:asa]]

(In reply to Dão Gottwald [:dao] from comment #85)
> Dolske, Zimbra has been fixed (I have no idea why you're implying the
> workaround might be unacceptable), Google was known to be affected, pinged
> long before and again now that the code was live. I don't see why this can't
> remain on mozilla-central *to get a better sense of what breaks*,
> evangelize, and back it out from aurora or beta if we think it breaks too
> many things for the respective audience (same plan of action as for any
> other change).

For one because we won't know what breaks in the long tail. We'll simply be breaking things for our users. For what? How is this not completely backwards. Why aren't we looking for ways to make our UA string more compatible with the Web rather than less?

Comment 91

[Dão Gottwald [:dao]]

(In reply to Asa Dotzler [:asa] from comment #90)
I assume by "more compatible" you mean adding more data (the webkit way). See bug 572650 for why we don't want to send more data. Also, the UA string cannot be made fully compatible with all stupid things sniffers could possibly do, since adding cruft encourages yet more bad sniffing. Reducing the sniffing surface and making it more comprehensible and predictable makes it more forward compatible.

Comment 92

[Asa Dotzler [:asa]]

(In reply to Dão Gottwald [:dao] from comment #91)
> (In reply to Asa Dotzler [:asa] from comment #90)
> I assume by "more compatible" you mean adding more data (the webkit way).
> See bug 572650 for why we don't want to send more data. Also, the UA string
> cannot be made fully compatible with all stupid things sniffers could
> possibly do, since adding cruft encourages yet more bad sniffing. Reducing
> the sniffing surface and making it more comprehensible and predictable makes
> it more forward compatible.

I don't agree with "we don't want to send more data" bug. That's a religious crusade that's been leading to a bunch of wrong changes that break our user with zero actual reward given the myriad other ways sites can track users without having to do any fingerprinting work. 

We should not be breaking the Web for our users to shave off tiny bits of fingerprintability. This is _not_ the way to help our users. This is user hostile.

And the UA string absolutely can and should be made *more* compatible without needing to be "fully compatible" (your words). We're in no position to shed users for purity here. 

These actions are user-hostile and I cannot believe we're continuing to shoot ourselves in the foot like this.

Forward compatibility is something to build into new work, not to force into old work when it makes backwards incompatibility a real problem today for real users.

This is the third or forth such change in as many months that broke the web for our users with no real benefit. Breaking major websites and filing a go-nowhere Tech Evangelism bug is not OK. This has to stop.

Comment 93

[Vic]

(In reply to Asa Dotzler [:asa] from comment #92)
> (In reply to Dão Gottwald [:dao] from comment #91)
> > (In reply to Asa Dotzler [:asa] from comment #90)
> > I assume by "more compatible" you mean adding more data (the webkit way).
> > See bug 572650 for why we don't want to send more data. Also, the UA string
> > cannot be made fully compatible with all stupid things sniffers could
> > possibly do, since adding cruft encourages yet more bad sniffing. Reducing
> > the sniffing surface and making it more comprehensible and predictable makes
> > it more forward compatible.
> 
> I don't agree with "we don't want to send more data" bug. That's a religious
> crusade that's been leading to a bunch of wrong changes that break our user
> with zero actual reward given the myriad other ways sites can track users
> without having to do any fingerprinting work. 
> 
> We should not be breaking the Web for our users to shave off tiny bits of
> fingerprintability. This is _not_ the way to help our users. This is user
> hostile.
> 
> And the UA string absolutely can and should be made *more* compatible
> without needing to be "fully compatible" (your words). We're in no position
> to shed users for purity here. 
> 
> These actions are user-hostile and I cannot believe we're continuing to
> shoot ourselves in the foot like this.
> 
> Forward compatibility is something to build into new work, not to force into
> old work when it makes backwards incompatibility a real problem today for
> real users.
> 
> This is the third or forth such change in as many months that broke the web
> for our users with no real benefit. Breaking major websites and filing a
> go-nowhere Tech Evangelism bug is not OK. This has to stop.

Oh come on now. What is user hostile is sending all this personal data to all the websites. 

Repeating the word "privacy" will not make it so. The Do-not-track feature actually makes a person who has enabled "do not track" feature more unique.

As in "Mozilla promises social, privacy-driven Firefox in 2012" - http://www.zdnet.co.uk/news/web-apps/2012/02/14/mozilla-promises-social-privacy-driven-firefox-in-2012-40095036/

1. Why do the websites need this data?

2. The websites will have to eventually fix the problems because they can no longer ignore the Firefox base. That is if it was pushed to the release version, many users would complain directly to the website.

3. What can be done so that the websites are fooled into thinking that yes they got that data, but it will remain static, it won't change when Firefox is updated.

Comment 94

[Matthias Versen [:Matti]]

The only benefit from the solution with a fixed build ID in a release build is not fingerprinting. All what you get is that you save a few bytes in each http request with the cost that you break many pages and a some of them are broken for a long time. Users that depend on those pages (in an intranet as example) will have no chance as to change the browser.
Compare the few saved bytes in the http request with the data that is transferred in the modern web and you get no benefit at all. I agree Asa that we shoot ourselves in the foot for nothing and that is something that I can't understand.

BTW: The UA will also not be more compatible if you add things, it will be more compatible if you don't touch it except the usual version number updates.

Comment 95

[Daniel C]

(In reply to Asa Dotzler [:asa] from comment #92)
> Breaking major websites and filing a
> go-nowhere Tech Evangelism bug is not OK.

You cannot say it is go-nowhere evangelism when the change lasted on trunk for such a short time. I think my comment 27 covers this. Yes, there will be unknown breakages in the long tail but that's true of all changes, including sites that are broken due to the change from a 1-digit version to a 2-digit version (which provides no real benefit to the user).

A long-term vision for the user-agent could lead to Firefox being the browser least susceptible to broken sniffing in the future. This bug was part of that.

Comment 96

[Dão Gottwald [:dao]]

(In reply to Asa Dotzler [:asa] from comment #92)
> This is the third or forth such change in as many months that broke the web
> for our users with no real benefit. Breaking major websites and filing a
> go-nowhere Tech Evangelism bug is not OK. This has to stop.

Bug 572652? Management fail -- the tracking-firefox10 flag got lost.
Bug 690287? Evangelism is actually working there. How would we have "stopped" this other than by changing the string in some other way?

Comment 97

[Dão Gottwald [:dao]]

Attachment: patch, updated to tip

Comment 98

[j.j.]

(In reply to Dão Gottwald [:dao] from comment #96)
> (In reply to Asa Dotzler [:asa] from comment #92)
> > This is the third or forth such change in as many months that broke the web
> > for our users with no real benefit. Breaking major websites and filing a
> > go-nowhere Tech Evangelism bug is not OK. This has to stop.
>
> Bug 572652? Management fail -- the tracking-firefox10 flag got lost.
> Bug 690287? Evangelism is actually working there. How would we have
> "stopped" this other than by changing the string in some other way?

Bug 687400? Bug 679971? Bug 694931?

Asa, what has to stop is breaking the web if it is avoidable
(removing "document.height" is of benefit for web compat just now).
Things have to be done more intelligent and planful, e.g. do it not immediately
(add warnings, promote it loudly and wait one year).

Here we have a dozen or more bugs with a lot of opinions and less coordination.
Suddenly something was implemented based ob Fennec's (bad) experience.

Assuming removal of the frozen date some time is the right thing, that's to be done:

- Do research what the UA string should look like (less likely to break things)
- Make a final decision
- PROMOTE that UA string 12 month before shipping.
  This info needs to land in any webmaster forum around the world:
  "Future Gecko/Firefox UA string will look like: ... "
  Don't aim just to the big US, UK or DE communities.
  Keep in mind that one broken major site we know of shadows lots of small sites.

(All this could have been done in preparation of the version 10 change to do all
in one shot, there were such proposals in the various bugs)

Comment 99

[Asa Dotzler [:asa]]

(In reply to Daniel Cater from comment #95)

> A long-term vision for the user-agent could lead to Firefox being the
> browser least susceptible to broken sniffing in the future. This bug was
> part of that.

How many users are you willing to sacrifice today to long term maybe possible future? Seriously? What's an acceptable number of users who decide that the other browsers on their machine work with the Web better than Firefox. And how do you intend to measure that to make sure it's within your acceptable range? Where's the plan for that? There isn't one. We're just going to cross our fingers. I think that's irresponsible.

Comment 100

[Morpheus3k]

Sorry, if I'm spamming a lot of people here, but I've read the whole bug comments and must share my thoughts:
I know Mozilla as a community to lead the web forward. It has always broke the web. Remember the time when the web was designed for Internet Explorer. Did Mozilla designed an "open source" Internet Explorer for web compatibility? No! It broke the web! Mozilla designed a browser based on standards.
Mozilla is part of the standardization. Mozilla leads the way.

Bad sniffing happens because every browser tries to match the UA from the other:
Internet Explorer: Mozilla/5.0 <- it is not a Mozilla browser
Webkit: (KHTML, like Gecko) <- it is not "like" Gecko
etc...

Either Microsoft, Apple nor Google has the courage to change the UA for backwards compatibility. Mozilla always did things for a better web. Even if it breaks something, maybe one day, we have a simple, non-fingerprinting UA in the web.
Remember: Mozilla gained market share and people to support the mission, because it makes things different and leading forward.
Don't be afraid of breaking things, break for the cause :)

Comment 101

[Ben Bucksch (:BenB)]

I think it was not wise to back this out so quickly. Esp. because Google explicitly said they will adapt *if and only if* we're settled on what we want. We were settled, and contacted them, and now you back out.

Which message does that send? A single site being more powerful than the most popular browser in the same country? We got that wrong. The spec rules, we implement, sites follow. Not one admin somewhere who took less than 5 minutes to think about his broken rule determining our actions for the whole world.

In fact, Justin wasn't even informed about the current status when be backed out, because he mentioned Zimbra being broken, although it was already fixed, but he backed out that fix, too.

That backout wasn't helpful or constructive. There is no harm in the Nightly (or Aurora even) being suboptimal on one site for a few weeks until the site gets fixed.

Comment 102

[Gervase Markham [:gerv]]

Both Morpheus3K and Asa: I'd suggest that grandstanding isn't going to help.

Morpheus3K: we can't just break the web without some analysis of the impact and consideration of the gain. Standing up and saying "well, it's the Right Thing!" begs the question.

Asa: the logical conclusion from comment #99 is that if a change would break some site somewhere, we should never make it, ever. (As it's never possible to measure breakage across the entire web.) That's never been our policy with regard to web compatibility and never will be, and I'm pretty sure the Gecko team will back me up on that. (If it were, we'd currently be running Firefox 9.1, with 9.2 to come, and going on to 9.99, because going to 2 digits broke some sites.) So come down off the burning deck and let's debate the change on its own merits.

It's been decided that the Fennec UA will have Gecko/N.N rather than a Gecko date. Therefore, it is in our best interests to flush out as many sites as possible which have problems with this. Putting the same change in Nightly, our testbed, is a fine way to do that.

There is a massive difference between making a change in Nightly and putting it in a released build. That's why we _have_ a train model. We currently know of one site (Google) which breaks when we make this change; how are we going to discover others if no-one uses a browser with the change in it? And why would sites bother to change their code if there seemed to be no prospect of the change making it to a released build?

As Ben says, we made the change, we re-contacted Google, and now we look deeply indecisive. That's not awesome.

Gerv

Comment 103

[Justin Dolske [:Dolske]]

(In reply to Ben Bucksch (:BenB) from comment #101)

> That backout wasn't helpful or constructive.

It made Google work again properly. Breaking top-tier website for an indefinite period is simply not acceptable.

TBH, I'm increasingly thinking mucking about with the UA is simply the wrong battle to be fighting at this time. It's an enormous time sink, attracts vast amounts of flames, and there are so much more important things to be fixing and investing time in.

Comment 104

[Ben Bucksch (:BenB)]

> Breaking top-tier website for an indefinite period is simply not acceptable.

* It wasn't indefinitely: Google had promised (bug 651674 comment 21) to fix their long-standing anyways-broken UA parsing, if we settle on something, and you just jeopardized that
* it was only Nightlies
* it wasn't "broken" as in completely unusable, but layout.

That's the whole point. I find the combination of point 1 and 2 particularly painful.

Comment 105

[Paul [pwd]]

Gerv articulates this perfectly. Most people understand and accept that the whole point of nightly is to test changes and give websites a chance to fix things before they reach the general public and that the whole point of the Evangelism team is to make sure that Mozilla products and any changes they make to their said products are supported by the widest possible audience.

Comment 106

[Dão Gottwald [:dao]]

(In reply to Gervase Markham [:gerv] from comment #52)
> I would love it if someone CCed on this bug would take on the task of
> looking at those 16 sites. I would anticipate it would be a couple of hours
> work to produce a report on which are false positives and which are broken,
> and file bugs on the broken ones.

Apart from google, the only affected site out of these 16 seems to be zillow.com. Filed bug 730604 on this.

Comment 107

[Vic]

Below was supposed to be posted here, instead of Bug 572659, which was listed as Fixed, Comment 112:

"It still showing in latest nightly when I ran a test at https://panopticlick.eff.org

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0) Gecko/20120226 Firefox/13.0a1

...

Its also showing the date of build?."

Comment 108

[[Baboo]]

(In reply to rsx11m from comment #57)
>  4. if the rv:x.x version is <2.0, the "Gecko/" token contains the build date
>  5. if the rv:x.x version is >=2.0, use navigator.buildID for the build date

Considering that Gecko/2.0 browsers are soon to become unsupported why should anyone sniff for them?


(In reply to Vic from comment #107)
> Its also showing the date of build?."

For nightly and aurora yes. Currently, the dummy date is only used in beta and release releases. Bug 728773 has been filed to use it also in aurora and nightly.

Comment 109

[rsx11m]

(In reply to [Baboo] from comment #108)
> Considering that Gecko/2.0 browsers are soon to become unsupported why
> should anyone sniff for them?

Because there is a difference between "being supported" and "being used" ... ;-)

Comment 110

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(Just a drive-by; I'm not really here, but happy to see someone trying to push this bug to a sane resolution…)

The discussion on what UA string format to use doesn't need to be hemmed in by what GeckoIsGecko.org recommends (and uses) *today*; while the recommendation has been static for years, it's because the UA string format was static for years (and the main recommendations haven't really changed even with the modified format of Gecko 2 and up), not because those recommendations were intended to be best practices forever.

So pick a nice, simple format that complies with the RFC, and once that's done and the dust has settled and no-one's trying to back things in and out, tell reed and me what the result is, and we'll update GeckoIsGecko.org to use and recommend the new heuristic.

Comment 111

[Dão Gottwald [:dao]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/f99cf2f41355

(This isn't committed to Gecko 15. Only looking for fallout at this stage.)

Comment 112

[Boris Zbarsky [:bzbarsky]]

Need to track to make sure we don't ship this when we don't mean to.

Comment 113

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/f99cf2f41355

Comment 114

[Phoenix]

(In reply to Boris Zbarsky (:bz) from comment #112)
> Need to track to make sure we don't ship this when we don't mean to.
So, you still thinks that "this" must be shipped?
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 
Hm, strange, 15 is mentioned only three times, that's may be not enough!

Comment 115

[Justin Dolske [:Dolske]]

(In reply to Justin Dolske [:Dolske] from comment #84)

> Here's what I think needs to happen before relanding:
> 
> 1) Use contacts at Google and Zimbra to fix problems on their end and
> estimate time to widely deploy. (Zimbra is of lesser importance if bug
> 572659 is an acceptable workaround).
> 
> 2) Get to a shared understanding with Firefox module owner/peers (that's
> me!) and product / release drivers regarding:
>   * What the cost of this change is (ie, what breaks)
>   * What the benefit of this change is (ergo, can discuss cost/benefit)
>   * Plan and action for disabling on aurora/beta/release, and when we expect
> to
>     be able to leave it on through release.
> 
> I don't really care what the UA contains, but I care very much about having
> sudden, unexpected breakage of major web sites.

Did I miss a discussion on point #2? As far as I can tell neither I, Gavin, nor Asa was aware this was was going to reland. Let alone the other points.

Comment 116

[Dão Gottwald [:dao]]

We currently don't seem to face a cost, and based on the gathered data and experience on mobile, there's a good chance that there's no significant yet-unknown cost. That said, I landed this not to ride the next release train but to gather more data and possibly uncover costs. The point of this is to enable us to discuss cost/benefit and what to do on aurora/beta/release.

Comment 117

[Asa Dotzler [:asa]]

(In reply to Dão Gottwald [:dao] from comment #116)
> We currently don't seem to face a cost, and based on the gathered data and
> experience on mobile, there's a good chance that there's no significant
> yet-unknown cost. 

You do not have the necessary data to support assertions of no cost. This will break sites. This will cost us users. 

Until someone can make an effective case, to the Firefox Product and Module owners, that there's some significant win for users or the Web, this change should be put on hold.

This change needs to be backed out and not re-landed without support from the Firefox Product and Module owners.

Comment 118

[Tony Mechelynck [:tonymec]]

In reply to comment #117: Indeed.

This,

Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/15.0 Firefox/15.0a1 SeaMonkey/2.12a1

is a nightly build. When I report a bug, how is the developer to know in which nightly I had the problem? Not everyone has Nightly Tester Tools installed, which would allow inserting the above UA string into a textbox with " ID:20120505003004" added at the end.

Comment 119

[Boris Zbarsky [:bzbarsky]]

> When I report a bug, how is the developer to know in which nightly I had the problem?

Because you paste in the url from about:buildconfig?  That's more useful information than the day the build was made on anyway, in general.

But in any case, this bug is not about nightly behavior.  We want to change our nightly UA to match our shipping UA, in general, which would mean using the frozen 2009 date in nightlies even if we revert the patch in this bug.  The "real" date, if needed, should be shown in about:support.

Comment 120

[Philip Chee]

> Because you paste in the url from about:buildconfig?
The SeaMonkey about:buildconfig doesn't show the:
Built from http://hg.mozilla.org/mozilla-central/rev/......

Comment 121

[Dave Garrett]

(In reply to Philip Chee from comment #120)
> > Because you paste in the url from about:buildconfig?
> The SeaMonkey about:buildconfig doesn't show the:
> Built from http://hg.mozilla.org/mozilla-central/rev/......

Filing a SeaMonkey bug to fix that sounds like a good idea.

Comment 122

[Daniel C]

(In reply to Tony Mechelynck [:tonymec] from comment #118)
> In reply to comment #117: Indeed.
> 
> This,
> 
> Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/15.0 Firefox/15.0a1
> SeaMonkey/2.12a1
> 
> is a nightly build. When I report a bug, how is the developer to know in
> which nightly I had the problem? Not everyone has Nightly Tester Tools
> installed, which would allow inserting the above UA string into a textbox
> with " ID:20120505003004" added at the end.

You can get the build date from the About dialogue (yyyy-MM-dd) or the more precise build ID (yyyyMMddHHmmss) by evaluating "window.navigator.buildID;" in the Web Console / Error Console / Scratchpad.

Bug 589444 is for putting that information in about:support.

Comment 123

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Asa Dotzler [:asa] from comment #117)
> You do not have the necessary data to support assertions of no cost. This
> will break sites. This will cost us users [...]
> This change needs to be backed out and not re-landed without support from
> the Firefox Product and Module owners.

I disagree. 
Nightly (pre-alpha builds) are for testing proposes.

How we can get necessary data if only a few guys will be testing this or what's worse the test will be performed by programmed bots basing on some web ranking.
Better test real life cases.

Don't forget also that alpha testers can easily revert this change in about:config if they want
and of course this patch can be only available on Nightly builds, if it's not stable enough, like for ex. pipelining

Comment 124

[Dão Gottwald [:dao]]

(In reply to Asa Dotzler [:asa] from comment #117)
> (In reply to Dão Gottwald [:dao] from comment #116)
> > We currently don't seem to face a cost, and based on the gathered data and
> > experience on mobile, there's a good chance that there's no significant
> > yet-unknown cost. 
> 
> You do not have the necessary data to support assertions of no cost.

The data supporting what I said is attached to this bug.

> This will break sites. This will cost us users.

I have no idea what this assertion is based on.

> Until someone can make an effective case, to the Firefox Product and Module
> owners, that there's some significant win for users or the Web, this change
> should be put on hold.
>
> This change needs to be backed out and not re-landed without support from
> the Firefox Product and Module owners.

This change is outside of the Firefox module's scope. Product can relax as long as we only gather feedback in nightlies. As I said, this doesn't ride a release train yet.

Comment 125

[Tony Mechelynck [:tonymec]]

(In reply to Daniel Cater from comment #122)
[...]
> You can get the build date from the About dialogue (yyyy-MM-dd) or the more
> precise build ID (yyyyMMddHHmmss) by evaluating "window.navigator.buildID;"
> in the Web Console / Error Console / Scratchpad.

Now that this bug has landed, there is no build date in the About: dialog, it has been replaced by the Gecko version. As for evaluating window.navigator.buildID, that's the first word I hear of it, and I don't expect newbies (or even seasoned testers who aren't developers) to be able to suck it out of their thumb.

> 
> Bug 589444 is for putting that information in about:support.

Thanks, I just CC'd myself.

(In reply to Philip Chee from comment #120)
> > Because you paste in the url from about:buildconfig?
> The SeaMonkey about:buildconfig doesn't show the:
> Built from http://hg.mozilla.org/mozilla-central/rev/......

Yes it does, under the "Source" heading (2nd from top), at least in current trunk builds. For instance this May 6 nightly (ID=20120506003023) was built from mozilla-central changeset 94ce5f33a9ea.

What it doesn't show is the comm-central changeset, which has to be got from the .txt file found on the FTP server, next to the corresponding .tar.bz2 (or .dmg or pair of .zip and .installer.exe).

Comment 126

[Daniel C]

(In reply to Tony Mechelynck [:tonymec] from comment #125)
> (In reply to Daniel Cater from comment #122)
> [...]
> > You can get the build date from the About dialogue (yyyy-MM-dd) or the more
> > precise build ID (yyyyMMddHHmmss) by evaluating "window.navigator.buildID;"
> > in the Web Console / Error Console / Scratchpad.
> 
> Now that this bug has landed, there is no build date in the About: dialog,

By "About dialogue" I meant Help -> About Nightly, not the about: page. You should see the version number and date, e.g.: 15.0a1 (2012-05-06).

This bug is just about the HTTP User-Agent string, where the build date serves no purpose, is different to the release string, leads to bad sniffing, etc. Any broken sniffers found whilst this fix is on trunk should be evangelised (I'll happily work on any TE bugs filed). The broken sites that were found the first time around (Google and Zimbra) are no longer a problem.

Broken sniffers are bad for the Web and cause problems for new browsers (http://webaim.org/blog/user-agent-string-history/). Having this fix in Nightly builds means that those sniffers are much more likely to be identified and fixed.

Comment 127

[Tony Mechelynck [:tonymec]]

(In reply to Daniel Cater from comment #126)
[...]
> By "About dialogue" I meant Help -> About Nightly, not the about: page. You
> should see the version number and date, e.g.: 15.0a1 (2012-05-06).
[...]

In SeaMonkey (just like it used to do in Netscape), Help → About opens the about: page.

Comment 128

[Robert Kaiser]

(In reply to Tony Mechelynck [:tonymec] from comment #125)
> Now that this bug has landed, there is no build date in the About: dialog

That's a SeaMonkey bug and should be reported and fixed as such. It might be a good idea to fix it in both the generic and the SeaMonkey about: pages but in the end, it's a separate bug from this one here, it's been a bug for a while that the Gecko date in the UA string even showed a moving date, it really should have been frozen everywhere for fingerprinting reasons.

Please file a SeaMonkey bug and/or one against the generic about: page to include the build date.

Comment 129

[Tony Mechelynck [:tonymec]]

(In reply to Robert Kaiser (:[e-mail]) from comment #128)
[...]
> Please file a SeaMonkey bug and/or one against the generic about: page to
> include the build date.

bug 752797

Comment 130

[Dão Gottwald [:dao]]

Attachment: backout patch for upcoming Aurora merge

want more baking time on mozilla-central

Comment 131

[Alex Keybl [:akeybl]]

Comment on attachment 629797 [details] [diff] [review]
backout patch for upcoming Aurora merge

[Triage Comment]
This backout is approved for Aurora 15.

Comment 132

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/cbb22b5d1f6e

I'd request tracking-firefox16 now if that flag existed...

Comment 133

[Dão Gottwald [:dao]]

Attachment: aurora 16 backout

[Approval Request Comment]
requesting aurora 16 backout for bug 778408

Comment 134

[Scoobidiver (away)]

It's not backed out from Aurora.

Comment 135

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/16d4b9df3cd3

Comment 136

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Uh, we shipped this?

Comment 137

[Gervase Markham [:gerv]]

Yep. It slowly rode the trains, dropping off several times while things were prepared, getting wider and wider testing. Bugs in sites were found and fixed; at least one workaround (for Moodle) was written. It had as much testing as we could give it.

I've not been working today, but tomorrow I will look into the bugs that have been filed.

Gerv

Comment 138

[j.j.]

Anyone here to update the MDN docs soon?

Comment 139

[Ed Morley [:emorley]]

(In reply to j.j. (inactive in 2012) from comment #138)
> Anyone here to update the MDN docs soon?

I just attempted a go at updating them (it's a wiki, anyone can edit), but I'm no good with the various versioning banners and such, and there are also four related pages that I think could do with being combined (given how important they are, and even though some marked obsolete, I think there is still the risk of confusion).

https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference
https://developer.mozilla.org/en-US/docs/Browser_detection_using_the_user_agent
https://developer.mozilla.org/en-US/docs/Gecko_User_Agent_Strings
https://developer.mozilla.org/en-US/docs/User_Agent_Strings_Reference

Comment 140

[Gervase Markham [:gerv]]

I've updated the two of those docs which are current.

Gerv

Comment 141

[j.j.]

https://developer.mozilla.org/en-US/docs/Firefox_17_for_developers
needs update too, at least for posterity

Comment 142

[j.j.]

(and there was no release note?!
http://www.mozilla.org/en-US/firefox/17.0/releasenotes/)

Comment 143

[karl155]

@MDN docs:
I think when sniffing for Gecko based browsers "Gecko/" should be sniffed, not "Gecko" + "rv:". Sniffing "Gecko/" allows dropping the (now redundant) "rv:" token sometime in the future.

Relevant for:
https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference

Comment 144

[Gordon P. Hemsley [:GPHemsley]]

(In reply to karl155 from comment #143)
> @MDN docs:
> I think when sniffing for Gecko based browsers "Gecko/" should be sniffed,
> not "Gecko" + "rv:". Sniffing "Gecko/" allows dropping the (now redundant)
> "rv:" token sometime in the future.
> 
> Relevant for:
> https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference

I agree.

Incidentally, the freeze will take place (eventually) in bug 729089. And the removal will take place (eventually) in bug 588913.

Comment 145

[Masatoshi Kimura [:emk]]

We should add a warning saying something like "Don't rely on rv: token. It will be removed in future." because we used to recommending rv: token.

Comment 146

[Dão Gottwald [:dao]]

(In reply to Masatoshi Kimura [:emk] from comment #145)
> We should add a warning saying something like "Don't rely on rv: token. It
> will be removed in future." because we used to recommending rv: token.

Note that we're not committed to removing it and may never reach a point where it wouldn't break too many sites. That said, we can still try to push people by saying that we intend to remove the token at some point.

Comment 147

[Gervase Markham [:gerv]]

(In reply to karl155 from comment #143)
> @MDN docs:
> I think when sniffing for Gecko based browsers "Gecko/" should be sniffed,
> not "Gecko" + "rv:". Sniffing "Gecko/" allows dropping the (now redundant)
> "rv:" token sometime in the future.

Given our experience with removing the Gecko date, I think it's highly unlikely it will ever be worth removing the rv: token. Even if it causes a small amount of breakage, it's not really worth it. And I bet a _lot_ more scripts check it, because it's the one consistent way we've provided over recent years of determining Gecko version. To save 7 or 8 characters, you need a very minimal downside. I'd even go so far as WONTFIXing those bugs, and reconsidering the situation in (say) 5 years.

Gerv

Comment 148

[Dave Garrett]

Could someone please just delete this page:
https://developer.mozilla.org/en-US/docs/Gecko_User_Agent_Strings
and make that URL redirect to this page instead:
https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference

There's really no content of value on the old one.

Comment 149

[Asa Dotzler [:asa]]

(In reply to Gervase Markham [:gerv] from comment #147)
> I'd even go so far as WONTFIXing those bugs,
> and reconsidering the situation in (say) 5 years.

Please.

Comment 150

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Asa Dotzler [:asa] from comment #149)
> (In reply to Gervase Markham [:gerv] from comment #147)
> > I'd even go so far as WONTFIXing those bugs,
> > and reconsidering the situation in (say) 5 years.
> 
> Please.

What good will WONTFIXing do if there's a plan to revisit the situation in the future? It's not like they're getting any current action.

Comment 151

[j.j.]

(In reply to Dave Garrett from comment #148)
> Could someone please just delete this page:
> https://developer.mozilla.org/en-US/docs/Gecko_User_Agent_Strings
> and make that URL redirect to this page instead:
> https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference
> 
> There's really no content of value on the old one.

Please file a bug in
Product: Mozilla Developer Network
Component: Documentation

Comment 152

[(no longer active)]

I'm backing this and the follow-up fixes out in bug 815743.

Comment 153

[Ed Morley [:emorley]]

MDN docs need reverting now :-/

Comment 154

[Dave Garrett]

(In reply to j.j. (inactive in 2012) from comment #151)
I filed bug 815855 for the obsolete doc removal/redirect. (not affected by this bug)

Comment 155

[Gervase Markham [:gerv]]

edmorley: they need re-updating, not backing out; there were many fixes in my checkin which were not specifically related to this issue. I'll go and do that now.

Gerv

Comment 156

[Gervase Markham [:gerv]]

I re-updated the UA docs.

Gerv