Closed Bug 244485 Opened 16 years ago Closed 13 years ago
Build ID only generated when MOZILLA
_OFFICIAL is set
We need the Build ID to be generated for some Firefox features to differentiate between different builds. Unfortunately this is only generated in builds when MOZILLA_OFFICIAL is set in the environment. It should be generated unconditionally.
Alternatively, the same information can be generated and placed elsewhere, as I hear there are implications to layout link performance.
Status: NEW → ASSIGNED
The date portion of the UA was intended to be a "source" date, not a build date. If it were generated as part of the *checkout* target it would not cause undue extra linkage in layout. On the plus side developer builds would have meaningful and consistent build ID's. On the down side there might not be a way to distinguish official release "re-spins". Does that happen often enough (without re-pulling) to matter?
We're gonna need a different date for "gecko" and for the "app" anyway, once we separate the build. The gecko buildid should be used for the useragent, but the app buildid (probably on uniqueness-crack) should be used for profile-uniqueness.
Any progress here?
2 years and no update? This is still a problem with the current Minefield Build on Win XP SP2. It happened to me today while doing Litmus testing. In Minefield: Help>About Minefield comes back with a build ID of 20070308, which is 2 numbers short of the 10 digit number required. about: in the address bar returns 0000000000. litmus.mozilla.org reports 0000000000 as the build ID as well.
Assignee: bugs → nobody
Status: ASSIGNED → NEW
Product: Mozilla Application Suite → Core
With all the build ID changes in last couple of months, is this still an issue?
This was fixed by bug 383167.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.