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

RESOLVED WONTFIX

Status

()

Core
Networking: HTTP
RESOLVED WONTFIX
7 years ago
3 years ago

People

(Reporter: dwitte@gmail.com, Assigned: dao)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {dev-doc-needed, relnote})

Trunk
mozilla15
dev-doc-needed, relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15+ disabled, firefox16+ disabled, firefox17 disabled, firefox18 disabled, firefox19 disabled, firefox20 disabled, firefox-esr17 disabled)

Details

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
Blocks: 588913

Comment 1

7 years ago
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).
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

7 years ago
> (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...

Updated

7 years ago
Depends on: 572659, 572661
(Reporter)

Comment 4

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

Any idea how many, roughly?
No, I just know we truncated the UA string date to avoid problems.

Comment 6

7 years ago
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.
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → Trunk
(Reporter)

Comment 7

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

Let's make this bug about moving the 'rv:' value to Gecko/.
OS: All → Linux
Hardware: All → x86_64
Summary: Replace Gecko/<date> with Gecko/<majorversion> in UA string → Replace Gecko/<date> with Gecko/<version> in UA string
Version: Trunk → unspecified
Yahoo used the year in the past (2009:bug 471816, 2008:bug bug 410430)
(Reporter)

Comment 9

7 years ago
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.
(Reporter)

Comment 10

7 years ago
Created attachment 467576 [details] [diff] [review]
patch

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

Gecko/2.0b5pre (X11; Linux x86_64; rv:2.0b5pre) Minefield/4.0b5pre
Assignee: nobody → dwitte
Status: NEW → ASSIGNED
Attachment #467576 - Flags: superreview?(jst)
Attachment #467576 - Flags: review?(jduell.mcbugs)
(Reporter)

Comment 11

7 years ago
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

7 years ago
(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
(Reporter)

Comment 13

7 years ago
Yes.

Comment 14

7 years ago
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.
(Reporter)

Comment 15

7 years ago
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.
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

7 years ago
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

7 years ago
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.
(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.
(Reporter)

Updated

7 years ago
Attachment #467576 - Flags: superreview?(jst)
Attachment #467576 - Flags: review?(jduell.mcbugs)
(Reporter)

Comment 20

7 years ago
Not gonna do this.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX

Comment 21

7 years ago
> 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.
(Reporter)

Comment 22

7 years ago
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

7 years ago
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.

Updated

6 years ago
Blocks: 651503
(Assignee)

Comment 24

5 years ago
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>.
Assignee: dwitte → dao
Status: RESOLVED → REOPENED
Depends on: 671634
OS: Linux → All
Hardware: x86_64 → All
Resolution: WONTFIX → ---
(Assignee)

Updated

5 years ago
Blocks: 572661
No longer blocks: 651503
No longer depends on: 572661, 572659
(Assignee)

Updated

5 years ago
Duplicate of this bug: 651503
(Assignee)

Comment 26

5 years ago
Created attachment 593346 [details] [diff] [review]
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...
Attachment #467576 - Attachment is obsolete: true
Attachment #593346 - Flags: superreview?(gerv)
Attachment #593346 - Flags: review?(bzbarsky)
(Assignee)

Updated

5 years ago
Keywords: dev-doc-needed
Target Milestone: --- → mozilla13
Version: unspecified → Trunk

Comment 27

5 years ago
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

5 years ago
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

5 years ago
(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 on attachment 593346 [details] [diff] [review]
patch

r=me
Attachment #593346 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 31

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

Comment 32

5 years ago
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.
(Assignee)

Comment 33

5 years ago
(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

5 years ago
One more alternative, if it's for free:
Mozilla/5.0 (Windows NT 6.1; WOW64) Gecko/13 Firefox/13.0
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
(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

5 years ago
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

5 years ago
(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

5 years ago
> What is the rationale

Rationale in bug 572659

Comment 40

5 years ago
(i.e. no need to *introduce* something that could be problematic.)
(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

5 years ago
(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

5 years ago
(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.
(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

5 years ago
(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

5 years ago
Created attachment 593973 [details]
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.
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
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.
(Assignee)

Comment 49

5 years ago
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

5 years ago
(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

5 years ago
> 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".
(In reply to Robert Kaiser (:kairo@mozilla.com) 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 on attachment 593346 [details] [diff] [review]
patch

sr=gerv.

Gerv
Attachment #593346 - Flags: superreview?(gerv) → superreview+
(Assignee)

Comment 54

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/bfc937247f3c
https://hg.mozilla.org/mozilla-central/rev/bfc937247f3c
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Depends on: 728566

Updated

5 years ago
Depends on: 651674

Updated

5 years ago
Blocks: 649435

Comment 56

5 years ago
I hope there are plans to promote this!?
tracking-firefox13: --- → ?

Updated

5 years ago
Blocks: 660498

Comment 57

5 years ago
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
(Assignee)

Updated

5 years ago
Duplicate of this bug: 660498
(Assignee)

Updated

5 years ago
No longer depends on: 728566

Updated

5 years ago
Depends on: 728610

Updated

5 years ago
Depends on: 723760
(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

5 years ago
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...  ;-)
(Assignee)

Updated

5 years ago
No longer depends on: 723760

Comment 61

5 years ago
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.
So, this landing regressed Google, and completely broke Zimbra.

Who's backing this out? Me?
(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

5 years ago
(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

5 years ago
(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.
> 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

5 years ago
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.
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 :-/
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

5 years ago
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.
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.
(In reply to Robert Kaiser (:kairo@mozilla.com) 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.
Depends on: 728797
(Assignee)

Comment 73

5 years ago
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] (khuey@mozilla.com) 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.
(Assignee)

Comment 74

5 years ago
(In reply to Dão Gottwald [:dao] from comment #73)
> (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) 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.
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
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

5 years ago
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.
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

5 years ago
Done, that's bug 728856.
Depends on: 728856

Comment 80

5 years ago
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.
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

5 years ago
(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.

Updated

5 years ago
Depends on: 589444

Comment 83

5 years ago
(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.
(Assignee)

Updated

5 years ago
No longer depends on: 589444
Depends on: 728972
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 85

5 years ago
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).
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.
(Assignee)

Comment 87

5 years ago
(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.
(Assignee)

Comment 88

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

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

Comment 89

5 years ago
(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)
Status: REOPENED → ASSIGNED

Comment 90

5 years ago
(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?
(Assignee)

Comment 91

5 years ago
(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

5 years ago
(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

5 years ago
(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.
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

5 years ago
(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.
(Assignee)

Comment 96

5 years ago
(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?
(Assignee)

Comment 97

5 years ago
Created attachment 599035 [details] [diff] [review]
patch, updated to tip

Comment 98

5 years ago
(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)

Updated

5 years ago
No longer blocks: 586165

Comment 99

5 years ago
(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

5 years ago
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 :)
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.
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
(Assignee)

Updated

5 years ago
No longer blocks: 588913
(Assignee)

Updated

5 years ago
Blocks: 572650
(Assignee)

Updated

5 years ago
Blocks: 729089

Updated

5 years ago
tracking-firefox13: ? → +
(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.
> 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.
Depends on: 729348

Comment 105

5 years ago
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.

Updated

5 years ago
Depends on: 726587
(Assignee)

Updated

5 years ago
No longer depends on: 726587
(Assignee)

Updated

5 years ago
Depends on: 730604
(Assignee)

Comment 106

5 years ago
(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

5 years ago
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

5 years ago
(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

5 years ago
(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" ... ;-)
(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.
(Assignee)

Updated

5 years ago
tracking-firefox13: + → ---
(Assignee)

Comment 111

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

(This isn't committed to Gecko 15. Only looking for fallout at this stage.)
Target Milestone: mozilla13 → mozilla15
Need to track to make sure we don't ship this when we don't mean to.
tracking-firefox15: --- → ?
https://hg.mozilla.org/mozilla-central/rev/f99cf2f41355
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
tracking-firefox15: ? → +

Comment 114

5 years ago
(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!
Depends on: 751366
(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.
(Assignee)

Comment 116

5 years ago
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

5 years ago
(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.
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.
> 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

5 years ago
> 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

5 years ago
(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

5 years ago
(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.
(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
(Assignee)

Comment 124

5 years ago
(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.
(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

5 years ago
(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.
(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

5 years ago
(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.
Blocks: 752797
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #128)
[...]
> Please file a SeaMonkey bug and/or one against the generic about: page to
> include the build date.

bug 752797
Depends on: 754680
(Assignee)

Comment 130

5 years ago
Created attachment 629797 [details] [diff] [review]
backout patch for upcoming Aurora merge

want more baking time on mozilla-central
Attachment #593346 - Attachment is obsolete: true
Attachment #629797 - Flags: approval-mozilla-aurora?
Comment on attachment 629797 [details] [diff] [review]
backout patch for upcoming Aurora merge

[Triage Comment]
This backout is approved for Aurora 15.
Attachment #629797 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 132

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

I'd request tracking-firefox16 now if that flag existed...
status-firefox15: --- → wontfix
Target Milestone: mozilla15 → mozilla16
(Assignee)

Updated

5 years ago
tracking-firefox16: --- → ?
tracking-firefox16: ? → +

Updated

5 years ago
Depends on: 776376

Updated

5 years ago
Depends on: 778408
(Assignee)

Comment 133

5 years ago
Created attachment 647485 [details] [diff] [review]
aurora 16 backout

[Approval Request Comment]
requesting aurora 16 backout for bug 778408
Attachment #629797 - Attachment is obsolete: true
Attachment #647485 - Flags: approval-mozilla-aurora?
Attachment #647485 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 134

5 years ago
It's not backed out from Aurora.
status-firefox16: --- → affected
(Assignee)

Comment 135

5 years ago
http://hg.mozilla.org/releases/mozilla-aurora/rev/16d4b9df3cd3
status-firefox16: affected → wontfix

Updated

5 years ago
Depends on: 789023
(Assignee)

Updated

5 years ago
Depends on: 792054

Updated

5 years ago
Depends on: 797703

Updated

5 years ago
Depends on: 780393
(Assignee)

Updated

5 years ago
No longer depends on: 797703
(Assignee)

Updated

5 years ago
Depends on: 799502
(Assignee)

Updated

5 years ago
No longer depends on: 754680
status-firefox15: wontfix → disabled
status-firefox16: wontfix → disabled
Target Milestone: mozilla16 → mozilla15

Updated

5 years ago
Depends on: 808440
Depends on: 814263
Depends on: 814019
Depends on: 814127
Depends on: 814336
Depends on: 814138
Uh, we shipped this?
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
Depends on: 814529

Updated

5 years ago
Depends on: 814970

Comment 138

5 years ago
Anyone here to update the MDN docs soon?
(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

Updated

5 years ago
status-firefox17: --- → fixed
I've updated the two of those docs which are current.

Gerv

Comment 141

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

Comment 142

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

Updated

5 years ago
Keywords: relnote
Depends on: 815190

Comment 143

5 years ago
@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
(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.
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.
(Assignee)

Comment 146

5 years ago
(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.
(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
Depends on: 815597

Comment 148

5 years ago
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.
Depends on: 815615

Comment 149

5 years ago
(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.
(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.
Depends on: 815631

Comment 151

5 years ago
(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
Depends on: 815743
I'm backing this and the follow-up fixes out in bug 815743.
Resolution: FIXED → WONTFIX
MDN docs need reverting now :-/
status-firefox17: fixed → disabled
status-firefox18: --- → disabled
status-firefox19: --- → disabled
status-firefox20: --- → disabled
status-firefox-esr17: --- → wontfix
status-firefox-esr17: wontfix → disabled

Comment 154

5 years ago
(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)
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
I re-updated the UA docs.

Gerv
Depends on: 817062
Depends on: 817361

Updated

4 years ago
Blocks: 817450
You need to log in before you can comment on or make changes to this bug.