We have an iMac running 10.8.1 in the UX room in SF ("Orpheum") that doesn't want to update from 14.0.1 to 15.0. (If you have physical access to the room, you should be able to check it out in person.) Sometimes it shows "Firefox is up to date", and sometimes it shows "Get updates at http://www.firefox.com". I verified that it's not a permissions problem: $ whoami mozilla $ ls -l /Applications/Firefox.app total 16 drwxr-xr-x@ 8 mozilla admin 272 Jul 13 14:59 Contents -rw-r--r--@ 1 mozilla admin 7287 Jul 13 14:59 precomplete Here's what in the Error Console when I try to update (this is when it says "Firefox is up to date"): AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/14.0.1/20120713134347/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/default/default/update.xml?force=1 AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.org/update/3/Firefox/14.0.1/20120713134347/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/default/default/update.xml?force=1 Timestamp: 8/29/12 9:48:05 AM Error: mismatched tag. Expected: </meta>. Source File: https://aus3.mozilla.org/update/3/Firefox/14.0.1/20120713134347/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/default/default/update.xml?force=1 Line: 15, Column: 3 Source Code: </head> AUS:SVC Checker:onProgress - 511/511 AUS:SVC Checker:onLoad - request completed downloading document AUS:SVC Checker:updates get - unexpected node name! AUS:SVC Checker:onLoad - there was a problem checking for updates. Exception: Error: Unexpected node name, expected: updates, got: parsererror AUS:SVC Checker:onLoad - request.status: 500 AUS:SVC getStatusTextFromCode - transfer error: Internal server error (500), code: 500 When it asks me to download it from firefox.com, the error log looks like this: AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/14.0.1/20120713134347/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/default/default/update.xml?force=1 AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.org/update/3/Firefox/14.0.1/20120713134347/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/default/default/update.xml?force=1 aus3.mozilla.org : server does not support RFC 5746, see CVE-2009-3555 AUS:SVC Checker:onProgress - 892/892 AUS:SVC Checker:onLoad - request completed downloading document AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/14.0.1/20120713134347/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/default/default/update.xml?force=1 AUS:SVC Checker:onLoad - number of updates available: 1

It almost seems to me that there's some network issues here. The error parsing XML is REALLY weird, and it almost seems as if it was receiving HTML instead of XML. Also, the fact that it gets "up to date" sometimes and "Get updates at" other times is very strange. Those are different failure modes, for sure.

The error parsing is likely due to an intermittent network or server issue (if I recall correctly it fallsback to an html error page) when under a heavy load. The download update is likely due to the permissions not being what we need to update. We have seen upgrades to Mac OS X resetting permissions and we can only update in this scenario when the same user that installed Firefox performs the update on Mac OS X. Bug 394984 will remedy that once we have resources to work on it.

(In reply to Ben Hearsum [:bhearsum] from comment #1) > > Also, the fact that it gets "up to date" sometimes and "Get updates at" > other times is very strange. Those are different failure modes, for sure. The about dialog doesn't display all of the error conditions due to requirements placed by UX to simplify it when it was implemented. Evaluating the following in the error console with the about dialog closed will bring up the check for updates ui which has the additional error information const Cc = Components.classes; const Ci = Components.interfaces; Components.classes["@mozilla.org/updates/update-prompt;1"].createInstance(Components.interfaces.nsIUpdatePrompt).checkForUpdates();

Hmmm, could be related to bug 786649 if it's likely to be network related.

Tried again, got: AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/14.0.1/20120713134347/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/default/default/update.xml?force=1 AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.org/update/3/Firefox/14.0.1/20120713134347/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/default/default/update.xml?force=1 aus3.mozilla.org : server does not support RFC 5746, see CVE-2009-3555 AUS:SVC Checker:onProgress - 892/892 AUS:SVC Checker:onLoad - request completed downloading document AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/14.0.1/20120713134347/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/default/default/update.xml?force=1 AUS:SVC Checker:onLoad - number of updates available: 1 AUS:SVC UpdateService:removeDownloadListener - no downloader! When I run the command from comment 3, I get: "…you do not have the system permissions required to install it." The permissions on the file itself is: drwxr-xr-x@ 4 mozilla admin 136 Jul 13 14:59 Firefox.app However, "mozilla" is the current user, and all the files seem to be owned by the mozilla user. I will attach a full directory listing of all the files next.

We've seen this before and I am quite certain that this part of the bug report is a dupe of bug 394984. An easy way to test if it is: 1. Download the build that has an update available (e.g. 14.0.1) 2. Rename the existing bundle in the applications directory. 3. Install the build you downloaded. 4. Check for updates by opening the about dialog. 5. Update should succeed as long as the network or server isn't overloaded / having problems (other part of the bug report). All of the above steps MUST be done from the same user account.

…and now it suddenly wanted to update to 15.0, but gets stuck here on the "connecting to update server".

We've also seen that with network contention...

I have brought this up several times and I'll mention it again her. We really should be throttling if the network or the server can't handle the load.

There was (and possibly still is) an issue with Bouncer (bug 786649), which could be causing the new issue. When it says "Connecting to update server", is that AUS, or whatever the MAR URL is?

I think jlin at the Toronto office is hitting the same issue.

I got the same dialogue box as limi in Comment 8. Relogging in as the same user that installed firefox solved the problem for me - it was able to auto update.

(In reply to Jonathan Lin [:jlin] from comment #13) > I got the same dialogue box as limi in Comment 8. Relogging in as the same > user that installed firefox solved the problem for me - it was able to auto > update. Thanks and that is bug 394984

So this is a dupe then?

For the summary regarding not being able to update. The network issues are separate and often happen on release days since we have been doing them unthrottled. What happens regarding the network or server contention issues should be a different bug in the correct component so duping.

(In reply to Jonathan Lin [:jlin] from comment #13) > I got the same dialogue box as limi in Comment 8. Relogging in as the same > user that installed firefox solved the problem for me - it was able to auto > update. Yes, I understand that it will solve the issue if that is the case. However, it doesn't look like that's what's happening here — there's only one user on the system, "mozilla", and the permission on all the files under (and including the top level) directory are all owned by "mozilla". So I doubt this is the same thing.

Damn it, Bugzilla — I didn't touch that field. :P

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #17) > (In reply to Jonathan Lin [:jlin] from comment #13) > > I got the same dialogue box as limi in Comment 8. Relogging in as the same > > user that installed firefox solved the problem for me - it was able to auto > > update. > > Yes, I understand that it will solve the issue if that is the case. However, > it doesn't look like that's what's happening here — there's only one user on > the system, "mozilla", and the permission on all the files under (and > including the top level) directory are all owned by "mozilla". So I doubt > this is the same thing. All I can say is I have seen this exact same thing happen in other bug reports where OS X has changed the permissions. To verify if this is the case please follow the steps in comment #7

Limi: Were you running Firefox 14.0.1 Funnelcake?

(In reply to Chris More [:cmore] from comment #20) > Limi: Were you running Firefox 14.0.1 Funnelcake? I don't think so; but this is the UX room public computer, so maybe. How could I check?

In About Firefox it will say 'Funnelcake' and 'mozilla11' (or 12, 13, or 14).