User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
In Preferences, under Advanced>Software Installation, I have "Enable software
installation" and "Check for updates [weekly]" both selected. I have never been
notified of any available updates, since 1.4 or even earlier.
Steps to Reproduce:
1. Set Preferences to enable software installation and check for updates.
Reported new versions of Mozilla as they became available.
SeaMonkey 1.0a: IT WORKS!!! :D
http://www.adrianer.org/updates.rdf as update_notifications.provider.0.datasource
update_notifications.provider.0.frequency with "1"
and update_notifications.enabled "true"
Reproducable: sometimes. Not on every machine reproducable (probably a problem
with extensions like Multizilla). On my laptop without Multizilla update
notifications works, on my PC with Multizilla id dosen't work.
WHEN this works, then a new key "update_notifications.provider.0.last_checked"
have been made.
It is interesting that SM 1.0 finds updates for the product "Mozilla" but not
for "SeaMonkey". Probably SM identifites itself internally as "Mozilla"?
Bug #285696 had to do with product's name but I guess nobody would work on it...
The decision was made to branch the SeaMonkey off of the Mozilla trunk because
of lots of reasons.
(In reply to comment #2)
> The decision was made to branch the SeaMonkey off of the Mozilla trunk because
> of lots of reasons.
Who told you that crap? Suite trunk is SeaMonkey. I'm not sure what this update
functionality does or how it works though, so I can't tell what it is or isn't
finding and why.
The update functionality is this what we see under Preferences/Advanced/Software
Installation/Update Notifications. This since Mozilla 1.4 (or older) USELESS
(because nothink happans) UI seems o function since SeaMonkey 1.0a (when we
specify an extenal updates.rdf file).
(xpfe/components/updates/src). It seeks in an external updates.rdf file for the
version number of a possibly new release and if the version number is greater
than the version number of the program itself then it opens a window with a site
offering the update (the url of the site is in the updates.rdf file).
More information: http://www.mozilla.org/xpapps/updates/spec.html
I think we should turn the update notification function on for SeaMonkey 1.0,
because i see, that for example in Poland, 50% of Mozilla Suite users usess an
older version than 1.7.0(!).
Zook meant probably the problem that i mentioned in comment #1:
"It is interesting that SM 1.0 finds updates for the product "Mozilla" but not
for "SeaMonkey". Probably SM identifites itself internally as "Mozilla"?"
It seems that an internal product name of SeaMonkey is Mozilla, because when
searching for updates it SM 1.0a finds updates for Mozilla and not for itself...
Created attachment 197928 [details]
Mozilla Updates Notifications - functioning confirmation window
Created attachment 197930 [details]
Mozilla Updates Notifications - functioning download window
I would say that we would probably be looking at making use of the same update
mechanism as FF/TB (i.e. nsUpdateService).
(In reply to comment #5)
> It seems that an internal product name of SeaMonkey is Mozilla, because when
> searching for updates it SM 1.0a finds updates for Mozilla and not for itself...
Could it be that it's just taking whatever it finds in the RDF? So if you change
to an RDF that states "SeaMonkey" as productName it refers to "SeaMonkey"?
(In reply to comment #8)
> I would say that we would probably be looking at making use of the same update
> mechanism as FF/TB (i.e. nsUpdateService).
You mean the new one that in theory understand binary diffs? Would surely be
nice to have - would you make up a patch and drive it into brabch even before
Beta? If no, I guess it would be nice to try and use the cheap notification
stuff we already have in our code...
(In reply to comment #9)
> Could it be that it's just taking whatever it finds in the RDF? So if you change
> to an RDF that states "SeaMonkey" as productName it refers to "SeaMonkey"?
It searches in the rdf for the own product name. WHEN it would find a
"SeaMonkey" update, it would probably use it as the name. The problem is, that
when i make an updates.rdf who only is an update for "SeaMonkey" (for example
one that i host here: http://www.adrianer.org/updatesseamonkey.rdf ), SM 1.0a
finds nothink. So it seems, that SM 1.0a has in some place internally an
hardcoded "Mozilla" product name.
i've done a new test now and it finds ands display an update for "SeaMonkey" :D
I probably found my mistake:
The update finder doesn't seek for a version, for example: 220.127.116.1150910, but
for the "rv:1.8b4" and/or "Gecko/20040910"... i'm doing some more tests now...
Now i know more... sorry for my mistakes in the firsts comments.
Test done with updates.rdf like this:
This is the Version compare code from the nsUpdateNotifier.js:
var parts = aStringVersion.split('.');
var len = parts.length;
this.mMajor = (len >= 1) ? this.getValidInt(parts) : 0;
this.mMinor = (len >= 2) ? this.getValidInt(parts) : 0;
this.mRelease = (len >= 3) ? this.getValidInt(parts) : 0;
this.mBuild = (len >= 4) ? this.getValidInt(parts) : 0;
if (this.mMajor == aOther.mMajor)
if (this.mMinor == aOther.mMinor)
if (this.mRelease == aOther.mRelease)
if (this.mBuild <= aOther.mBuild)
return true; // build is newer
else if (this.mRelease < aOther.mRelease)
return true; // release is newer
else if (this.mMinor < aOther.mMinor)
return true; // minor is newer
else if (this.mMajor < aOther.mMajor)
return true; // major is newer
var integer = parseInt(aString);
The "nsVersion.prototype" function is really an prototype.
It seems that to identifity the 1.8b5 20050929 build itself it needs to be in
the updates.rdf as "1.8b5.0.20050929".
When the script was written down, nobody thinked it could be letters in the
"rv"... If this function would be only turned on in stable releases this would
be not a problem, but this must be solved in an another way... but this should
be not to problematic to solve, i hope.
Comment #2, #3 and #5 - My apology. Questions or concerns, please use my email
instead of this bug report.
Adrian, saw your comment, comment #2 in bug #283580. Once it's working then any
change of moving it to update.mozilla.org or ?????.mozilla.org or something like
wiki (spelling??)? Or have someone to maintain it?
(In reply to comment #13)
> Once it's working then any
> change of moving it to update.mozilla.org or ?????.mozilla.org or something like
> wiki (spelling??)? Or have someone to maintain it?
Don't be concerned, we'll only check a URL into the tree that's tightly
maintainable by the SeaMonkey Council (who is in control of releases as well)
and that's somewhere at mozilla.org - we'll see in what way it is manageable
best. First we need to know a way to upgrade builds well enough though, meaning:
a user of a final should not be warned about a more recent alpha/beta but only a
new final. It would be nice though to warn users of an alpha when the beta
arrives and of alpha/beta when a final arrives.
(In reply to comment #14)
> Don't be concerned, we'll only check a URL into the tree that's tightly
> maintainable by the SeaMonkey Council (who is in control of releases as well)
> and that's somewhere at mozilla.org - we'll see in what way it is manageable
> best. First we need to know a way to upgrade builds well enough though, meaning:
> a user of a final should not be warned about a more recent alpha/beta but only a
> new final. It would be nice though to warn users of an alpha when the beta
> arrives and of alpha/beta when a final arrives.
The only possible think that functions without writing tons of new code is that
we use more than one updates.rdf file.
I think we should have:
-one file group for the stable releaeses - for EACH language an OWN file, so
that an update information will be only displayed when the localised new release
is avaiable, for example a file:
-one file group for the unstable alpha, beta and rc releaeses - for each
language an OWN file, so that an update information will be only displayed when
the localised new release is avaiable, for example a file:
So in the stable releases would be the first url included, in the unstable the
second. The second updates.rdf would be == the first updates.rdf when we release
an stable release (and didn't have in the same time an next alpha... when it
were so we must think about an thirt group of the files).
A question: am i right, when i say that we ONLY have this kind of version
nummering systems (based on examples):
the i think about patching the code from my last comment... (comment #12)
Created attachment 209613 [details] [diff] [review]
patch: add a SeaMonkey-specifc updates URL
OK, here's a patch that should set a working URL for stable releases, and we can use that from 1.0 upwards (given that the patch makes it into that release).
I'll upload a RDF identically to the one in comment #12, only with the version changed to 18.104.22.16860125 (will be corrected to the real date once final gets released).
I'm just not sure if releases/updates.en-US.rdf or releases/updates/en-US.rdf is better (note that we should get one file per supported laguage)...
Comment on attachment 209613 [details] [diff] [review]
patch: add a SeaMonkey-specifc updates URL
a=me for 1.1
seeing as you're also council, I'll count you as first a= for 1.0, so a=me,kairo for 1.0
checked in on trunk and both branches (with the URL changed to releases/updates/en-US.rdf) and uploaded the RDF file.
I hope it works now and people will get a warning if we do updates in the future...
To be valid RDF, you should replace "about" with "RDF:about" on the 5th line of releases/updates/en-US.rdf
(See http://www.w3.org/2000/03/rdf-tracking/#rdf-ns-prefix-confusion )
(In reply to comment #19)
> To be valid RDF, you should replace "about" with "RDF:about" on the 5th line of
done that, I hope we also use it correctly then (but I guess we should, as we have a good XML parser and model AFAIK) :)