Closed Bug 817450 Opened 7 years ago Closed 6 years ago

Nightly & Aurora's UA should use the same frozen build date as Beta & Release (20100101)

Categories

(Firefox :: General, defect)

19 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 728773
Tracking Status
firefox19 --- affected
firefox20 --- affected

People

(Reporter: davemgarrett, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

With bug 588909 now reverted, release builds are back to the frozen build date "Gecko/20100101". Development builds are now back to having the current build date. This reintroduces this sniffing surface back to development builds. The frozen build date should be used on all builds so that Mozilla tests what it actually ships, rather than changing it just for the final release.
Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17a1 ID:20121202003011 c-c:118ec2f9e401 m-c:2533bce8e045

In this SeaMonkey trunk nightly (whose UA string ends just before ID:), the "Gecko build date" is, as you can see, the frozen bogus date 20100101.

Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20121202 Firefox/20.0 ID:20121202030723

In this Firefox Nightly, OTOH, the "actual" build date is present.

This difference between Firefox and SeaMonkey means, IIUC, that this bug belongs somewhere in Firefox, not in Core.
Component: Networking: HTTP → Untriaged
Product: Core → Firefox
It's also applicable to Aurora builds.
Component: Untriaged → General
Version: Trunk → 19 Branch
For the record, the worry here is these two possible cases:

1) A web developer tests a new feature in a development build so that it will be ready to be used before the final Firefox release containing it. If they sniff the UA and require a build date at least as new as the development build to enable the feature (which would be logical with a non-frozen build date), then it will be disabled by the sniffing site on release.

2) It is possible that something could be currently sniffing for "20100101" and will provide different content for a newer build date (or any build date it does not recognize). Testing this site would produce different results in the release versus a development build.

UA sniffing is a mess of possible problems so if we're now set on keeping the frozen date then it would be best to be as consistent as possible with it.
Seems results of last UA change didn't hit some people hard enough so they continue proposing useless UA changes because of some imaginary security concerns.
Guys, maybe you do something really *useful* instead of this time waste? You know, there are a lot of real bugs around, which annoys Mozilla users and their fix can give more gain that dumb games around UA.
(In reply to Phoenix from comment #4)
> Seems results of last UA change didn't hit some people hard enough so they
> continue proposing useless UA changes because of some imaginary security
> concerns.
> Guys, maybe you do something really *useful* instead of this time waste? You
> know, there are a lot of real bugs around, which annoys Mozilla users and
> their fix can give more gain that dumb games around UA.

Re-read comment 0. This is increasing our confidence in testing, when using Nightlies etc; as opposed to changing the UA in release builds.

Please also take a look at https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Summary: Don't expose the Gecko build date in the UA string for development builds → Nightly & Aurora should use the same frozen 20100101 build date as Beta & Release
Summary: Nightly & Aurora should use the same frozen 20100101 build date as Beta & Release → Nightly & Aurora's UA should use the same frozen build date as Beta & Release (20100101)
This seems to have been replaced by bug 728773 for all channels (and all Gecko applications for that matter), thus should be marked as either WFM or a dupe of the other bug.
Whiteboard: [closeme]
Yep, got done in another bug.

Current Aurora UA:
Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0

Current Nightly UA:
Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0

Duping to where it got done then.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 728773
Whiteboard: [closeme]
You need to log in before you can comment on or make changes to this bug.