therube wrote:Suppose we'll have the actual build date & FF will have that "magic" date (20100101).
You should see the change with tomorrow's nightly builds, but I guess that's how it will be (i.e., just backing out the related changes, thus restoring the old UA).
The first tinderbox build (tested #1354057952, build ID 20121127151232, for beta on Windows) shows the date again, so that worked. According to the patch, the fixed "Gecko/20100101" token should only be effective for Firefox builds.
rsx11m wrote:Now, this has shipped with Gecko 17.0 (i.e., SeaMonkey 2.14) as we know, but today it was apparently decided to back this out from all branches, including release, thus there will be a Gecko 17.0.1 respin (SM 2.14.1) with the Gecko build date restored in the UA string.
Fire 750, bring back 250. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript
rsx11m wrote:Now, this has shipped with Gecko 17.0 (i.e., SeaMonkey 2.14) as we know, but today it was apparently decided to back this out from all branches, including release, thus there will be a Gecko 17.0.1 respin (SM 2.14.1) with the Gecko build date restored in the UA string.
Wonder if it had anything to do with my feedback on Nightly reporting that was my only problem. Shortly after submitting that feedback Eshan was added to the CC list of my bug report, and I saw it mentioned in today's meeting notes.
therube wrote:They said it was "leak", whatever that means?
Memory leaks = you allocate some memory for performing a specific task, and after that task is finished, you are supposed to free that memory again. There are automated leak tests for this, and apparently the separate Moodle fix caused it, hence it was retained but preffed off (i.e., disabled) in the follow-up fix.
There is some more information on the reasoning of the backout following BenB's inquiry (bug 815743 comment #31). This seems to be a rather semi-permanent won't-fix for now, given Gerv's comment that it's unlikely to be attempted again within a year (but it's not clear how authoritative that statement is). My guess is that they'll try to push it again before the next ESR branch is cut (with Gecko 24.0), but then they'd need a better approach for communicating the change to the rest of the world beforehand so that widely used sniffing methods can be adjusted.
therube wrote:Suppose we'll have the actual build date & FF will have that "magic" date (20100101).
Great...
Bug 816749 introduced the "20100101" nonsense now for SeaMonkey and Thunderbird as well in a 30-min action. Thus, in fact we've still lost the build date in the UA string.
therube wrote:Suppose we'll have the actual build date & FF will have that "magic" date (20100101).
Great...
Bug 816749 introduced the "20100101" nonsense now for SeaMonkey and Thunderbird as well in a 30-min action. Thus, in fact we've still lost the build date in the UA string.
Help->About SeaMonkey will still show the buildID.
That's a crappy fudge.
BTW, I'll keep using my own 'custom' user agent ...
Help->About SeaMonkey will still show the buildID.
That's not the point!
That really sucks! We're suppose to be better then FF!
Anyone file a bug yet?
Fire 750, bring back 250. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript
Well, I'd rather hope that bug 816749 is backed out again to facilitate a proper discussion if there are any benefits in freezing the date at all (and I'd think that the burden of proof lies with the proponents of such a change, not with us), keeping the state prior to bug 588909 until such determination has been made.
In Linux i see no gecko string stuff at all in these forums.i must admit that my version of seamonkey is from Linux repos and not the binary from http://www.seamonkey-project.org/ ==> Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14
For Firefox, there is now bug 817450 to freeze the build date also in their nightly and aurora builds. In contrast to SeaMonkey, they are using the branding to determine whether or not to override it by the dummy date, whereas SeaMonkey has it hardwired in the configuration variables that apply to all builds (thus, the FF-to-SM port of this "feature" wasn't even correct in this regard).
mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.
Definitely, these guys of mozilla corp. are morons ...
