271745 - Software installation and check for updates has no effect

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Greg Colyer]

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.

Reproducible: Always
Steps to Reproduce:
1. Set Preferences to enable software installation and check for updates.
2. Wait.

Actual Results:  
Nothing.

Expected Results:  
Reported new versions of Mozilla as they became available.

Comment 1

[Adrian Kalla [:adriank]]

SeaMonkey 1.0a: IT WORKS!!! :D

Tested with:
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"?

Comment 2

[Zook Valem]

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.

Comment 3

[Robert Kaiser]

(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.

Comment 4

[Adrian Kalla [:adriank]]

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).

The Update functionality seems to be only one Javascript 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(!).

Comment 5

[Adrian Kalla [:adriank]]

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...

Comment 6

[Adrian Kalla [:adriank]]

Attachment: Mozilla Updates Notifications - functioning confirmation window

Comment 7

[Adrian Kalla [:adriank]]

Attachment: Mozilla Updates Notifications - functioning download window

Comment 8

[Ian Neal]

I would say that we would probably be looking at making use of the same update
mechanism as FF/TB (i.e. nsUpdateService).

Comment 9

[Robert Kaiser]

(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...

Comment 10

[Adrian Kalla [:adriank]]

(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.

Comment 11

[Adrian Kalla [:adriank]]

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: 1.0.0.20050910, but
for the "rv:1.8b4" and/or "Gecko/20040910"... i'm doing some more tests now...

Comment 12

[Adrian Kalla [:adriank]]

Now i know more... sorry for my mistakes in the firsts comments.

Test done with updates.rdf like this:
<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:NC="http://home.netscape.com/NC-rdf#">

  <RDF:Description about="urn:updates:latest">
    <NC:registryName>Browser</NC:registryName>
    <NC:version>1.8b5.0.20050929</NC:version>
    <NC:URL>http://www.mozilla.org/projects/seamonkey/releases/</NC:URL>
    <NC:productName>SeaMonkey</NC:productName>

  </RDF:Description>

</RDF:RDF>




This is the Version compare code from the nsUpdateNotifier.js:

function nsVersion(aStringVersion)
{
  var parts = aStringVersion.split('.');
  var len = parts.length;

  this.mMajor   = (len >= 1) ? this.getValidInt(parts[0]) : 0;
  this.mMinor   = (len >= 2) ? this.getValidInt(parts[1]) : 0;
  this.mRelease = (len >= 3) ? this.getValidInt(parts[2]) : 0;
  this.mBuild   = (len >= 4) ? this.getValidInt(parts[3]) : 0;
}

nsVersion.prototype =
{
  isNewerThan: function(aOther)
  {
    if (this.mMajor == aOther.mMajor)
    {
      if (this.mMinor == aOther.mMinor)
      {
        if (this.mRelease == aOther.mRelease)
        {
          if (this.mBuild <= aOther.mBuild)
            return false;
          else
            return true; // build is newer
        }
        else if (this.mRelease < aOther.mRelease)
          return false;
        else
          return true; // release is newer
      }
      else if (this.mMinor < aOther.mMinor)
        return false;
      else
        return true; // minor is newer
    }
    else if (this.mMajor < aOther.mMajor)
      return false;
    else
      return true; // major is newer

    return false;
  },

  getValidInt: function(aString)
  {
    var integer = parseInt(aString);
    if (isNaN(integer))
      return 0;
    return integer;
  }
}


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 13

[Zook Valem]

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?

Comment 14

[Robert Kaiser]

(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.

Comment 15

[Adrian Kalla [:adriank]]

(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: 
http://www.mozilla.org/projects/seamonkey/releases/en-us/stable/updates.rdf
-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:
http://www.mozilla.org/projects/seamonkey/releases/en-us/unstable/updates.rdf

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):

1.   1.8.0.20051001
2.   1.8.0.2005100113
3.   1.8.20051001
4.   1.8.2005100113
5.   1.8a.0.20051001
6.   1.8a.0.2005100113
7.   1.8a.20051001
8.   1.8a.2005100113
9.   1.8b1.0.20051001
10.  1.8b1.0.2005100113
11.  1.8b1.20051001
12.  1.8b1.2005100113

the i think about patching the code from my last comment... (comment #12)

Comment 16

[Robert Kaiser]

Attachment: 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 1.8.0.20060125 (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 17

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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

Comment 18

[Robert Kaiser]

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...

Comment 19

[Xanthor Sccas]

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 )

Comment 20

[Robert Kaiser]

(In reply to comment #19)
> To be valid RDF, you should replace "about" with "RDF:about" on the 5th line of
> releases/updates/en-US.rdf

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) :)