209537 - mozilla.org/start does not recognise 1.4rc1 (release candidate 1)

Status: VERIFIED FIXED

(www.mozilla.org :: General, defect)

Description

[Andy Wood]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529

I was running 1.4 beta, then installed the Release Candidate as per the download
option on the main page of mozilla.org  After install, the browser re-opened,
but the site still thinks I'm running the old version.  All browser sessions and
open applications were closed before installation, including the quick launch
option on the system tray.


Reproducible: Always

Steps to Reproduce:
1.Open the Browser
2.go to http://www.mozilla.org/start/
3.

Actual Results:  
Hey! You're using an old version of Mozilla. We can really use your help testing
Mozilla 1.4 Release Candidate 1. Download it now! Thanks!

Expected Results:  
Should have recognized that I am supposed to be running RC1

Comment 1

[Stefan Borggraefe]

*** Bug 209540 has been marked as a duplicate of this bug. ***

Comment 2

[Waheed Islam]

reassigning to gerv (who made the change to rc1 & owner of start page).

this perhaps might not be fixed since the UA string of 1.4rc1 should have said
rv:1.4rc1, not... rv:1.4. (see bug 207695)


fix:

- var lm = "1.4rc1";
+ var lm = "1.4";


This is probably a wontfix, because of that.
But I'll leave that decision to gerv or endico.

Comment 3

[Matthias Versen [:Matti]]

*** Bug 209572 has been marked as a duplicate of this bug. ***

Comment 4

[Matthias Versen [:Matti]]

*** Bug 209416 has been marked as a duplicate of this bug. ***

Comment 5

[Matthias Versen [:Matti]]

*** Bug 209325 has been marked as a duplicate of this bug. ***

Comment 6

[hacker formerly known as [e-mail]]

*** Bug 209563 has been marked as a duplicate of this bug. ***

Comment 7

[Waheed Islam]

i can't find a commonality between those dupes, but this summary is (hopefully)
a little better.

Comment 8

[Gervase Markham [:gerv]]

Drat. This is all far too complicated. I'll apply a band-aid by changing the nag
time.

Gerv

Comment 9

[Andy Wood]

I have installed RC2, but the useragent still shows:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612

The "nag" on the main http://www.mozilla.org/start/ page was "fixed", but I just
wanted to let us know about the useragent text the browser is still "sending".

Comment 10

[Zibi Braniecki [:zbraniecki][:gandalf]]

Ok. I'll try to rewrite this, to meet requirements.
First of all i wan't to add recognizing for browser used. If someone use old
Netscape, let's give him link do the newest Netscape, if someone is using old
Firebird milestone, let's  give him link to the newest Firebird, same with
Galeon, SeaMonkey. Additional for Firebird and SeaMonkey nightly nagging.

My questions are:
1) Do we need support for somthing like in current script, about security
updates? (if so, it should be easy to manage - data stored in array)

2) Do we still use '+' as a nightly mark? I don't see it in my recent SeaMonkey
nightly build.

If thats what is needed, i'll be glad to help.

Comment 11

[Andrew Schultz]

Attachment: updated start page

This is a reasonable fixup for the start page

It does the following:
1. any version that is "less" than the current milestone ID is considered a
milestone build and the user is directed to the current milestone
2. any version that is "greater" than the current milestone ID is considered a
nightly and (if the builddate is old enough) the user is directed to latest
nightly.
3. if the version is equal to the current release ID, the JS checks the release
date.  if the build date is less than the release date AND it has been two
weeks since the build date, the user is directed to the milestone.
4. if none of the above are true, user is not nagged.

If Firebird is in the UA, it's version is used instead of the "rv:" and checked
against Firebird info.

Quirks:
1.4 branch nightly before rc1 was released would be considered a milestone
build, and would never trigger a nag (which seems reasonable).

Required info (for each "product"):
lmID: milestone as it appears in UA
lm: official milestone name
lm_releasedate: date milestone was released
latestmilestoneName: full name of milestone

(I have included a <base> tag so that the page renders "properly")

Netscape/Galeon, etc are not detected... I don't know why they would visit the
Mozilla start page and don't know why we need to redirect them to newer
non-Mozilla builds.

This also fixes bug 197297

comments (if I screwed up, it's because it's 5am)?

Comment 12

[Andrew Schultz]

Attachment: updated start page v2

don't alert() quite so much.

Comment 13

[Joris Huizer]

I think I can make the code a bit smaller without losing any functionality - by
using a few extra variables/functions to avoid typing too much multiple times
(like, the html for the <div> around the message is repeated every time! )

Do you think this is a good idea to do or won't it be necessary? These changes
might make things a bit easier to edit too (I did them on a copy of the page but
now I found the probs are allready solved... ! )

Comment 14

[Zibi Braniecki [:zbraniecki][:gandalf]]

Andrew, verification for other browsers is addon, i made part of code for
Firebird, and found that there could be also added other browsers.

At all I rewrited huge part of actual code. In my opinion current code is very
hard to modify, and is very bloated. It also does not fix problems with 1.3.1
vs. 1.4 or 1.0.3 vs 1.3.1rc1 !

I made 4 main presumptions:
1) Recognize if he use Mozilla distribution
2) Recognize what 'type' of Mozilla user is it (x.0.x - long term, x.x(.x)? -
stable, x.x(.x)?[rc|a|b] - milestones, nightlies)
3) Be able to lock type of browser if it's not developed (and link user to
something developed like with Phoenix->FireBird, or last version like with MacOS9)
4) Have a list of security bugs, and alert user who use older Gecko

I have to clean code now, and i'll send it here tommorow for Your verification.

Comment 15

[Andrew Schultz]

I forgot about the Phoenix/Firebird name switch (fixed it).

Also note that the method I used to identify a "nightly" depends on
ever-increasing versions.  That has not yet happened with Firebird (nightly
builds still identify themselves as 0.6).

Comment 16

[Alex Vincent [:WeirdAl]]

Do we really have to use document.write() so much?  Or can we have display:none
div elements, which we use standard DOM to adjust?

Comment 17

[Jesse Ruderman]

Using display:none instead of document.write would confuse text browsers and
search engines.  If you want to avoid document.write, use DOM 2 to create the
elements and append them to document.body.  I'd use document.write.

Comment 18

[Bill Mason]

Attachment: Another take on the script

Next time I'll check the bug during the day to see if any work's been done.  :)
 Here anyway is my take at trimming down the script while accomodating Firebird
and resolving bug 197927, bug 184770, and bug 152128.  Feel free to use or
ignore this go at it as one wishes.  :)

Comment 19

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: another try

Ok. My try. I tested it for whole day, but i'm still not sure if it's bug free.
I rewrited everything to target all bugs related to current script and to make
it easy to react on future situations (finish of SeaMonkey shipping, name
changes and so on, new bugs, platforms...)

I know it's quite big, but I couldn't find easier way to handle Mozilla type
used recognising. I hope Gerv is happy to see quite big response here, and he
can choose the best one :)

Comment 20

[Joris Huizer]

Well, I just had a look there, but the page now states "You're using Firebird
browser with old version of Gecko engine."

I'm using firebird 0.6 right now, which is the latest Firebird milestone; I
think it's weird to say I've got to upgrade !

The ua string is like this:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6

Comment 21

[Jo Hermans]

Even with a trunk-build of 2 days ago, I get a warning that I'm using an old
version ... (using attachment 126238 [details] from comment 19).

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030620

Comment 22

[Gervase Markham [:gerv]]

> Using display:none instead of document.write would confuse text browsers and
> search engines. 

This page is totally and exclusively designed for Mozilla, and for being its
start page. We do not need to worry about text browsers, or people finding it
using search engines. display: none would make the code much easier to read,
which I think outweighs the above considerations.

> 1) Do we need support for somthing like in current script, about security
> updates? (if so, it should be easy to manage - data stored in array)

No - that's old hat now.

> 2) Do we still use '+' as a nightly mark? I don't see it in my recent 
> SeaMonkey nightly build.

No, I don't think so - that's why we've been having problems recently. But you
need to investigate.

Gerv

If thats what is needed, i'll be glad to help.

Comment 23

[Bill Mason]

Attachment: Script without any document.write

Comment 24

[Andrew Schultz]

Attachment: updated start page v3

eliminates document.write, fixes Date handling, shuffles code around
eliminates security warning and fixes handling of 1.4a vs. 1.4

Comment 25

[Alex Vincent [:WeirdAl]]

Comment on attachment 126271 [details]
updated start page v3

First-look notes:

><SCRIPT type="text/javascript">
Hopefully we'll be able to take this and make it a <SCRIPT
src="sniffer.js"></SCRIPT> file.  Having all this inline, especially in the
body of the document, isn't necessarily a good design idea.  (More on this in a
moment.)

>  var msecsPerDay = 1000*3600*24;
>  // how long till we start nagging users of nightly builds
>  var nightlyLimit = 7*msecsPerDay;
>  // how long till we start nagging users of old milestone builds
>  var milestoneLimit = 14*msecsPerDay;

const instead of var here?  Also, consider making msecsPerDay = 86400000 (which
is what it evaluates out to).

>  var revision = ua.match(/rv:([\d\.\a]+)/);
>  // Search for the Firebird version in the User Agent string
>  var FBrevision = ua.match(/(Firebird|Phoenix)\/([\d\.\a]+)/);

Again, are these going to change?

>  if (nightly) {
>    document.getElementById("nagText").innerHTML+=" \
>      Your Mozilla nightly build is over a week old. Please help us \
>      out and grab a newer build. Thanks for testing Mozilla!";
>  } else {
>    document.getElementById("nagText").innerHTML+=" \
>      You\'re using an old version of Mozilla. We can really \
>      use your help testing " + latestmilestoneName +
>      ". Download it now! Thanks!";
>  }

innerHTML is EVIL!  Please set a text node's data property if you can.

>
>  var theLink=document.getElementById("nagLink");
>  if (isMacOSX) {

...

>  } else if (iswin32) {

...
>  } else if (isx86Linux) {

This is spaghetti.  Can we simplify this using select and case statements?  Or
compounded if statements:

if ((foo=true)&&(bar==true)) { ... }

Miscellaneous notes:  it's usually a good idea to separate code that modifies
the document from code that defines values and functions for the document. 
Maybe two separate script elements:  one in the head and another in the body. 
The head one should set all the variables and constants, while the one in the
body modifies the document.

You place a lot of variables into the global scope.  Most of that global-scope
code can be placed into a single function called from the global scope.

Also, perhaps (but I wouldn't hold you to this) an event listener can be used
to trigger showing and formatting the actual nag box:

window.addEventListener("load", function(evt) {
  userNagTest();
}, true);

Comment 26

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: Zbigniew's second try

Ok. Second try. Removed security check, fixed both bugs from Comment #20 (there
was bad release date of Firebird set) and Comment #21 (script did not break
after finding proper platform), reduced script size (especially smaller
CompareRevisions script), Download button added.
I also added suggestions from Comment #25 even i'm not sure we really need
functions. I did not used TextNode since it makes harder to push mixed text and
HTML code. But it also can be done.

At this point i'd like to know which way You want to go. Alex's, Bill's or
mine.	I'd like to test the chosen one to make it the best :)

Comment 27

[Andrew Schultz]

Comment on attachment 126287 [details]
Zbigniew's second try

> if (build[3] > lastMilestoneRelase && age > nightlyLimit) { // old Nightly build

this will give false positives (release detected as nightly).  not all release
builds are built on the official release day itself, and could be quite a bit
more recent (self-built or contributed builds).

Comment 28

[Zibi Braniecki [:zbraniecki][:gandalf]]

Ouch. You're right. I didn't know this. I took a look into Your solution, and
found part like
 if (buildDate > lastMilestoneRelease && revision!=lastMilestone)
This will be OK?

(secondly, in my Comment #26 s/Alex/Andrew/ - sorry Andrew)

Comment 29

[Andrew Schultz]

the comparisons I use would not work for any x.x.x revisions (1.3a > 1.3.1).  I
don't try to sniff out "stable" vs. "latest" milestone, so it's not a problem
for me.  

could you do something like
if ((buildDate > lastMilestoneRelease && revision==lastMilestone) ||
    (revision>lastMilestone)) {
   this is a nightly
}

where revision>lastMilestone would need to be done with your CompareRevisions.

Comment 30

[Andrew Schultz]

Comment on attachment 126287 [details]
Zbigniew's second try

> if (/^[0-9]+\.0\.[0-9]+/.test(revision[1])) { // x.0.x version

don't you want /^1\.0(\.[0-9]+)?/ here?

Comment 31

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: Zbigniew's third try

Ok. I fixed nightly sniffing part, with directions from Andrew.
About x.0.x - 1.0 is x.x(.x) or x.0(.x) branch?
(i also fixed 2 minor bugs - one with names and one with invalid break
placement)

Comment 32

[Dylan Schiemann]

IMO, this seems really complex for something that could in theory be a lot
easier.  I mean, you have four basic classes of users:

- conservative (1.0.x users)
- normal (stable releases only)
- aggressive (milestones only)
- developers (nightlies)

after 1.4, you'll have in theory a second conservative branch of 1.4.x users.

For conservative, normal, and aggressive users, you can keep an array of
releases, their user agent string, their order of release, and the date they
were released.  

something like:

mozRelease[mozRelease.length] = new Array(releaseType,userAgentString,releaseDate)

You can then filter by releaseType (stable, milstone, etc.).  This would also
let you suggest multiple upgrade paths... for example, if someone is using
1.2.1, you could suggest either 1.3.1, or 1.4rc2

For people downloading nightlies, I think they can figure out on their own when
to make an update.

As it is, this will break if yet another naming convention for releases comes
out, so this seems a lot simpler than trying to guess the future user agent
patterns.

Comment 33

[Bill Mason]

Attachment: Script w/o document.write (tweaked)

Just a quick fix added.

Comment 34

[Zibi Braniecki [:zbraniecki][:gandalf]]

Dylan: That is what i'm trying to make. But in Your analyse you forgot about not
supported anymore things (Mac OS 9), other browsers (like Firebird, Phoenix),
self builds and probably more things in the futur.

Your method (growing array) will require almost same parts as our work. You
still has to find if user uses older release than last one (and this is for each
'type' of user) - if he uses alpha, and rc1 is newer, you still has to check
platform to specify download link and so on.

Basicly, i think that Your method wont make whole code easier, but in futur it
will be huge (try to fill array containing all releases of Mozilla/Firebird
now!), but if You knowhow to make it a lot easier (which i cannot agree with
current requested behaviours), feel free. I'll make my best to help You.

Also about 1.4.x branch - no, it will be very easy - 
- if (/^[0-9]+\.0\.[0-9]+/.test(revision[1])) { // x.0.x version
+ if (/^[0-9]+\.[04]\.[0-9]+/.test(revision[1])) { // x.[04].x version

Comment 35

[Andrew Schultz]

Attachment: updated start page v4

I was assuming that a x.x.x release would never be the "latest" milestone, but
that hasn't been true (1.2.1).	I figured out how to simplify things further
and still handle x.x.x.

this also addresses Alex's comments

> This is spaghetti.

quite.	nobody seems able to agree on a naming scheme for directories or files.

I switched it to 
if (this && that) { link=there }
it looks better, unless your text editor wraps long lines.

> Maybe two separate script elements:  one in the head and another in the body.

> The head one should set all the variables and constants, while the one in the

> body modifies the document.

I put the sniffing into a function and put both in the head.  Since the part
that modifies the document is in a function, I don't know what separating them
accomplishes beyond making people scroll back and forth to see what's going on.


> window.addEventListener("load", function(evt) {
>   userNagTest();
> }, true);

is this really any different than a body onload handler (other than appearing
more complex)?

Comment 36

[[e-mail]]

>> window.addEventListener("load", function(evt) {
>>   userNagTest();
>> }, true);
>is this really any different than a body onload handler
This version would work in linked script, or anywhere where you might forget to
add the body onload handler.

> (other than appearing more complex)?
addEventListener("load", userNagTest, true);
would be the simple way of doing it. (Note: worth capturing load event?)

Comment 37

[Geoff Leach]

Self-builder here ...

I dont really know the number or fraction of self-builders. But I do suspect
they are growing (Gentoo Linux for starters). Maybe so few they can be ignored,
but I would prefer to see the nagger such that it is also reasonable for
self-builders.

Some feedback:

if (!CheckOtherBrowsers() && !/0{8}/.test(builddate[1])) { // other or self build

Self-builds do not have a gecko build date of 00000000 in the UA. Instead they
have a normal date, but which may be out-of-date due to the build process (more
detail in bug 184770). That will probably get fixed in time, and self-builders
can fix it themselves once they become aware of it. 

More generally though, nightlies can not be distinguished from self-builds from
information in the UA string. So if the revision > last milestone it could be
either a nightly or a self-build.

Suggest a change of wording from

"Your Mozilla nightly build is over a week old. Please help us out and grab a 
newer build. Thanks for testing Mozilla!"

to 

"Your Mozilla build is over a week old. Please help us out and use a newer
build. Thanks for testing Mozilla!"


Similar comments for the other nagger proposals.


Similar comments for the other two naggers.

Comment 38

[Bill Mason]

Attachment: Bill's v4

Incorporating some suggestions from the discussion in n.p.m.s.

Comment 39

[Bill Mason]

Attachment: Bill's v4.01

Typo fix.

Comment 40

[Zibi Braniecki [:zbraniecki][:gandalf]]

Gerv. Which way You want to go? I have two or three optimizations for my script
and the one from Comment #37 but i don't know if i should work on my script or
help testing Andrew's or Bill's one.

Comment 41

[Dylan Schiemann]

Yes, I hadn't considered the Mac OS 9 and other dropped platforms.  As far as
firebird and thunderbird go, in the scheme I presented, I consider those
nightlies until they replace seamonkey.

Really, though, I just took a look at all of this and thought that it was a lot
more difficult than it needed to be for this feature.  The RegEx approach you're
using makes sense if things stay consistent, but as soon as there is a change in
naming or numbering conventions for releases, it'll need to be updated... not
that an array approach wouldn't need to be, but it could be more easily 
automated.  The Array wouldn't get that large... a couple of hundred entries
after a year or two is still only 5-10K (assuming only milestone builds are
handled).  A separate array could be supplied for each platform to deal with the
deprecated platform issue.  Or we could use XMLHttpRequest or SOAP for this, and
grab a short tree of browser versions.

I'm not at all opposed to the current approach... just looking to help simplify
if possible.

Comment 42

[Zibi Braniecki [:zbraniecki][:gandalf]]

Dylan, my main idea was to check "other" browsers (Firebird, Netscape and so on,
where naming rules can be crazy) and then check Mozilla's builds/revisions where
naming system is stable like a hell and i hope wont change in near futur (except
'+' for nightlies and 0000000 for self-builds - both are managed by my current
script). If there is real denger that naming routines will change then You have
right. Secondly, I always prefer alghoritmic way than hardcoded arrays ;)

Comment 43

[Gervase Markham [:gerv]]

Guys,

I confess I don't really have time to evaluate the technical merits of the
various solutions here, so I'll just give me thoughts on what we'd like to
achieve, and see if they help.

Whatever solution we propose has to be:

- Low maintenance. Currently, it has to be updated every milestone release. This
doesn't sound like a lot, but it still doesn't get done. This page is locked
down in CVS because of its high visibility, so only a few people can update it.

- Fairly simple. Anything overly complicated will just be harder to understand
in six months time.

It doesn't matter too much what it says as long as it's accurate, and warns
people about nightlies. For example, a message which says roughly "Your build is
older than two weeks. We could use your help testing the latest nightly <here>
(warning: could be dangerous) or latest milestone <here>" would probably be fine
(i.e. just based on Gecko date). We don't necessarily need seven different
messages for sixteen different sets of people.

- It can use any JS supported by Mozilla; I don't care about it working in other
browsers. So use whatever produces the cleanest, nicest and most maintainable code.

- The security warning can go - the general upgrade one is sufficient.

- Ideally, self builders would get a message relating to the time they last
pulled from CVS. But that probably won't happen, so if there's no way to avoid
them getting strange and unexpected messages, then so be it. People who
self-build should have enough brains to ignore it if it doesn't apply to them.

If people have other, specific questions, feel free to pose them here (in new
messages, prefixed by "Gerv:" ;-), or mail me.

Keep up the good work, chaps :-)

Gerv

Comment 44

[Gervase Markham [:gerv]]

Of course, the page should also detect and cater for other mozilla.org browsers,
particularly Firebird (thanks to [e-mail] for this point.)

Gerv

Comment 45

[Bill Mason]

Attachment: Bill's v5

Very simple: if the build is 2 weeks old, asks user to get a new nightly or
milestone.  Looks for and generates appropriate links for Mozilla, Firebird,
and Camino.

Comment 46

[Geoff Leach]

I like the approach (attachment 126401 [details]) of linking to the releases page
http://www.mozilla.org/releases/ instead of directly to a download.

I would like to see a similar approach to nightlies, with a page
http://www.mozilla.org/nightlies, that has a short discussion about what
nightlies are, including caveat/warning, and a link to the nightlies download area. 

Also, my preference on the nag wording would be releases then nightlies:

Hey!  Your build is older than two weeks. We could use your help testing the
latest <a href="http://www.mozilla.org/releases">release</a> or latest <a
href="http://www.mozilla.org/nightlies">nightly</a>.

Comment 47

[Andrew Schultz]

Attachment: Andrew's v5

updated to completely ignore revision and milestone checks.  everything is back
into one function.

Comment 48

[Andrew Schultz]

Comment on attachment 126401 [details]
Bill's v5

>  var isMacos9 = uaString.match(/(Macintosh; [IUN]; PPC)/);

this actually matches OS X as well as OS 9 (see the example UAs in the original
URL).  Add a ";" to the end ( PPC; ) to exclude OS X.

Comment 49

[Bill Mason]

Attachment: Bill's 5.01

Includes fix from comment 48

Comment 50

[Daniel Wang]

can anyone please use the "Edit this Page" link at the bottom of the page to
make a patch?

Comment 51

[Gervase Markham [:gerv]]

Bill/Andrew: that looks pretty good. I'd just alter the text to be a bit more
expansive. How about:

"Hey! Your copy of <appname> is more than two weeks old. Unless you are using
the latest milestone build, bug reports get rapidly less useful the older your
copy is.

So, if you're not running the <a>latest milestone</a>, we could use your help
testing either that or the <a>latest nightly build</a>. (Be warned that nightly
builds are development software, and there is no guarantee that they won't fry
your processor, insult your mother, or cause you to break out in a nasty rash.)"

Gerv

Comment 52

[Bill Mason]

Attachment: Bill's v5.1

Revision incorporating last comments from Gerv.

Comment 53

[Andrew Schultz]

Attachment: Andrew's v5.1

updated wording

Comment 54

[Andrew Schultz]

Attachment: diff from the Doc

this is a patch from Doctor.  I seriously doubt anyone can read of this.  If
you want to see what I did, attachment 126884 [details] is highly recommended.

BTW: anonymous CVS access to mozilla-org as described in
http://www.mozilla.org/README-cvs.html is a lie.

Comment 55

[Gervase Markham [:gerv]]

Checked in. 

Checking in index.html;
/cvsroot/mozilla-org/html/start/index.html,v  <--  index.html
new revision: 1.49; previous revision: 1.48
done

Many thanks to all for making this happen. Please file bugs if you see any
problems with the new page.

Gerv

Comment 56

[Bill Mason]

Verified.

Comment 57

[Andy Wood]

I don't know if this is related to the start page or the browser itself.  I
think this all still relates to the UA the browser is sending.
The Start page is now complaining about the full release of 1.4 (Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624).  The releases page
shows a build date of 0630, but the installer shows the above date.

Comment 58

[Bill Mason]

Re-resolving as FIXED, someone can reopen if they disagree with this:

The script (Andrew's as well as mine, for that matter) is going to go entirely
by the date in the UA string.  As the scripts were evolving, to keep them
simple, any hardcoding of milestone names and actual release dates was
deliberately removed.  Even though 1.4 was released on 30 June, it actually
comes from a 24 June build.

See comment 43 for notes on keeping the script low maintenance and relatively
simple.

Comment 59

[Michael Lefevre]

what Bill said.  in fact, not only is 1.4 based on a build from the 24th June,
but of course that is based on a branch - the main code has had many significant
changes since the branch was created at the end of May.

if you want to test Mozilla and report bugs (and we want people to do that),
then it's better at this point to be using a trunk build - 1.5alpha is coming soon!

re-verifying.