"updated failed" 15.0 -> 15.0.1

VERIFIED FIXED in Firefox 16

Status

()

VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: cbeard, Assigned: Ehsan)

Tracking

({regression})

15 Branch
mozilla18
x86
Mac OS X
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-qa-testsuite -
in-testsuite -
in-moztrap +

Firefox Tracking Flags

(firefox15- affected, firefox16+ verified, firefox17+ verified, firefox18+ verified)

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
Steps to reproduce / observed behaviour:
1) open Firefox 15.0
2) Firefox > About Firefox
3) About Firefox dialog automatically checks for update, finds one, and appears to successfully download a 1.6MB file and then displays "Updated failed"
(Reporter)

Comment 1

6 years ago
Created attachment 659737 [details]
about dialog

screenshot of the about dialog, note that this is on Mac using Firefox 15.0 on the release channel
(Reporter)

Comment 2

6 years ago
and this is what shows up in the Error Console:

OpenGL LayerManager Initialized Succesfully.
Version: 2.1 NVIDIA-7.18.18
Vendor: NVIDIA Corporation
Renderer: NVIDIA GeForce 320M OpenGL Engine
FBO Texture Target: TEXTURE_2D

aus3.mozilla.org : server does not support RFC 5746, see CVE-2009-3555
Some additional information would be helpful. To get better logs:
* Set app.update.log to true
* Open & clear the error console
* Go to Help -> About to force an update check
* Paste all new lines from the error console into the bug

Also, zipping up update* from the appdir and attaching it here will give us more to go on. Please stop by #build if you have any trouble with this.
Do you run more than one profile out of the same install directory?
Chris, do you have any anti-virus or firewall software installed in that machine? Something like Norton Antivirus.

Comment 6

6 years ago
I just did an install on a vanilla Fx15 mac build, new profile.  Checking for updates found and installed 15.0.1 successfully.
(Reporter)

Comment 7

6 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #3)
> Some additional information would be helpful. To get better logs:
> * Set app.update.log to true
> * Open & clear the error console
> * Go to Help -> About to force an update check
> * Paste all new lines from the error console into the bug
> 
> Also, zipping up update* from the appdir and attaching it here will give us
> more to go on. Please stop by #build if you have any trouble with this.

It won't let me copy all the lines, so here is the line you might be looking for:

AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.org/update/3/Firefox/15.0/20120824154833/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2011.4.0/default/default/update.xml?force=1
(Reporter)

Comment 8

6 years ago
Created attachment 659785 [details]
error-console
(Reporter)

Comment 9

6 years ago
Here's something.  It looks like it's looking for a file from Comcast.  I switched to Comcast for my home internet a few weeks ago.  I didn't think it added anything to my Firefox but it now looks like it installed a search plugin.

In the file "/Applications/Firefox.app/Contents/MacOS/updates/last-update.log":

Performing a background update
SOURCE DIRECTORY /Applications/Firefox.app/Contents/MacOS/updates/0
DESTINATION DIRECTORY /Applications/Firefox.app/Updated.app
ensure_copy: failed to open the file for reading: /Applications/Firefox.app/Contents/MacOS/searchplugins/comcast.xml, err: 1
failed: 6
calling QuitProgressUI
The error console about there is a bit weird. It failed to apply the partial, but then complained about "update.status" not existing - which is new to me. Looping in some client-side updater folks who might have a better idea.

It would still be helpful for update* from the appdir to be attached, which may have other clues in it.
(Reporter)

Comment 11

6 years ago
Created attachment 659788 [details]
updates directory contents

here's my updates directory

Comment 12

6 years ago
Ok, looked through input.  Some data: 1) It's not very widespread (or at least users aren't complaining about it). There is nothing on SUMO and only 3 complaints that match on input:

https://input.mozilla.org/opinion/3194603
https://input.mozilla.org/opinion/3193394
https://input.mozilla.org/opinion/3169149

2) Looks to be OSX specific. If you end up in a stuck state then you can't get an update through the built in update UI going forward.
(In reply to Chris Beard from comment #9)
> Here's something.  It looks like it's looking for a file from Comcast.  I
> switched to Comcast for my home internet a few weeks ago.  I didn't think it
> added anything to my Firefox but it now looks like it installed a search
> plugin.
> 
> In the file
> "/Applications/Firefox.app/Contents/MacOS/updates/last-update.log":
> 
> Performing a background update
> SOURCE DIRECTORY /Applications/Firefox.app/Contents/MacOS/updates/0
> DESTINATION DIRECTORY /Applications/Firefox.app/Updated.app
> ensure_copy: failed to open the file for reading:
> /Applications/Firefox.app/Contents/MacOS/searchplugins/comcast.xml, err: 1
> failed: 6
> calling QuitProgressUI

Huh. It sounds like Comcast installed a file that the current user can't read. Can you "ls -l /Applications/Firefox.app/Contents/MacOS/searchplugins" and paste the output?
(Reporter)

Comment 14

6 years ago
-rw-r--r--  1 root  admin  1741 Jul 30 17:04 /Applications/Firefox.app/Contents/MacOS/searchplugins/comcast.xml
(Reporter)

Comment 15

6 years ago
I'm logged in as a user, and only have read permissions to this file. It looks like the Comcast files were installed as an admin.
(In reply to [:Cww] from comment #12)
> Ok, looked through input.  Some data: 1) It's not very widespread (or at
> least users aren't complaining about it). There is nothing on SUMO and only
> 3 complaints that match on input:
> 
> https://input.mozilla.org/opinion/3194603
> https://input.mozilla.org/opinion/3193394
> https://input.mozilla.org/opinion/3169149
> 
> 2) Looks to be OSX specific. If you end up in a stuck state then you can't
> get an update through the built in update UI going forward.

Those could be related to https://bugzilla.mozilla.org/show_bug.cgi?id=770996. This looks like a different problem.
(Reporter)

Comment 17

6 years ago
For the record it look like my instance of Firefox is all otherwise installed as my user, but within the admin group.  And I've been updated to update my Firefox until this release.

host-5-153:MacOS chris$ ls -ltr
total 159240
-rw-r--r--@  1 chris  admin     44553 Apr 20 17:36 removed-files
drwxr-xr-x@  3 chris  admin       102 Apr 20 17:38 extensions
drwxr-xr-x@  3 chris  admin       102 Apr 20 17:38 crashreporter.app
drwxr-xr-x@  3 chris  admin       102 Apr 20 17:38 updater.app
(Reporter)

Comment 18

6 years ago
s/updated/able
(Reporter)

Comment 19

6 years ago
host-5-153:searchplugins chris$ pwd
/Applications/Firefox.app/Contents/MacOS/searchplugins
host-5-153:searchplugins chris$ ls -ltr
total 64
-rw-r--r--  1 root   admin  1741 Jul 30 17:04 comcast.xml
-rw-r--r--@ 1 chris  admin  1309 Aug 28 08:01 yahoo.xml
-rw-r--r--@ 1 chris  admin  1391 Aug 28 08:01 wikipedia.xml
-rw-r--r--@ 1 chris  admin  2253 Aug 28 08:01 twitter.xml
-rw-r--r--@ 1 chris  admin  3581 Aug 28 08:01 google.xml
-rw-r--r--@ 1 chris  admin  1344 Aug 28 08:01 eBay.xml
-rw-r--r--@ 1 chris  admin  2465 Aug 28 08:01 bing.xml
-rw-r--r--@ 1 chris  admin  1607 Aug 28 08:01 amazondotcom.xml
OK, I think we have all the information we need at this point. Despite the update log saying that it's opening the file for reading, Catlee and I think it's trying to chmod or otherwise modify the file (https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp#512). I have a feeling that we used to handle unknown files in the appdir more gracefully, but because of the recent background updates work, a lot has changed there. It'd be really great to get Ehsan's input here to confirm.
(In reply to Ben Hearsum [:bhearsum] from comment #20)
> OK, I think we have all the information we need at this point. Despite the
> update log saying that it's opening the file for reading, Catlee and I think
> it's trying to chmod or otherwise modify the file
> (https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/
> updater/updater.cpp#512). I have a feeling that we used to handle unknown
> files in the appdir more gracefully, but because of the recent background
> updates work, a lot has changed there. It'd be really great to get Ehsan's
> input here to confirm.

Any hints from this on how QA can reproduce the failed partial?  so far, no one here can yet.
(Reporter)

Comment 22

6 years ago
(In reply to Tony Chung [:tchung] from comment #21)
> (In reply to Ben Hearsum [:bhearsum] from comment #20)
> > OK, I think we have all the information we need at this point. Despite the
> > update log saying that it's opening the file for reading, Catlee and I think
> > it's trying to chmod or otherwise modify the file
> > (https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/
> > updater/updater.cpp#512). I have a feeling that we used to handle unknown
> > files in the appdir more gracefully, but because of the recent background
> > updates work, a lot has changed there. It'd be really great to get Ehsan's
> > input here to confirm.
> 
> Any hints from this on how QA can reproduce the failed partial?  so far, no
> one here can yet.

Go into the searchplugins directory and chown one of the search plugins to root should do it
I'm 99% sure this is related to client-side updater changes.
Component: General → Application Update
Product: Firefox → Toolkit
It looks like ensure_copy is new code with bgupdates: https://hg.mozilla.org/mozilla-central/diff/c20d415ef1b5/toolkit/mozapps/update/updater/updater.cpp

I'm highly, highly suspicious that this is a new bug as of 15.0.
I managed to repro on linux by extracting a vanilla 15.0, adding a 'foo.xml' to searchplugins/, owned by root:root, and then trying to update. I ended up in an update loop back and forth between the partial and complete with this in the log:
Performing a background update
SOURCE DIRECTORY /home/bhearsum/tmp/firefox/updates/0
DESTINATION DIRECTORY /home/bhearsum/tmp/firefox/updated
ensure_copy: failed to open the file for reading: /home/bhearsum/tmp/firefox/searchplugins/foo.xml, err: 1
failed: 6
calling QuitProgressUI
(Assignee)

Updated

6 years ago
Assignee: nobody → ehsan
(Assignee)

Comment 27

6 years ago
OK, I can reproduce.  I'm currently building so that I can debug this.
(Assignee)

Updated

6 years ago
Blocks: 307181
Keywords: regression
cc'ing release management.  This may be a necessary bug to discuss a respin or new build.
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
Version: unspecified → 15 Branch
(In reply to Tony Chung [:tchung] from comment #28)
> cc'ing release management.  This may be a necessary bug to discuss a respin
> or new build.

The effected code may already be installed and running in v15.0.0, re-spinning to avoid an upgrade to v15.0.1 for some users may not help.
(Assignee)

Comment 30

6 years ago
The thing that is failing is this chmod call: <http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp#516>.  We basically try to set the permissions on every file that we open, including the ones that we open in read-only mode.

Now this was not a problem before bug 307181 since we did not have a call to ensure_open in read-only mode (starting from when this code was introduced: <http://hg.mozilla.org/mozilla-central/rev/a568cdcd510d>), but now we do on non-Windows platforms.  So we should just not chmod in those cases.
(In reply to Brian R. Bondy [:bbondy] from comment #29)
> (In reply to Tony Chung [:tchung] from comment #28)
> > cc'ing release management.  This may be a necessary bug to discuss a respin
> > or new build.
> 
> The effected code may already be installed and running in v15.0.0,
> re-spinning to avoid an upgrade to v15.0.1 for some users may not help.

If I understand the failure conditions here correctly, anybody with 15.0 or higher, and unwriteable files in their appdir is stranded completely.
(Assignee)

Comment 32

6 years ago
(In reply to Brian R. Bondy [:bbondy] from comment #29)
> (In reply to Tony Chung [:tchung] from comment #28)
> > cc'ing release management.  This may be a necessary bug to discuss a respin
> > or new build.
> 
> The effected code may already be installed and running in v15.0.0,
> re-spinning to avoid an upgrade to v15.0.1 for some users may not help.

I think it's best to fix this in 16, and perhaps consider writing an add-on hot-fix which detects this type of problem and sets app.update.stage.enabled to false for the affected users.
(Assignee)

Comment 33

6 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #31)
> (In reply to Brian R. Bondy [:bbondy] from comment #29)
> > (In reply to Tony Chung [:tchung] from comment #28)
> > > cc'ing release management.  This may be a necessary bug to discuss a respin
> > > or new build.
> > 
> > The effected code may already be installed and running in v15.0.0,
> > re-spinning to avoid an upgrade to v15.0.1 for some users may not help.
> 
> If I understand the failure conditions here correctly, anybody with 15.0 or
> higher, and unwriteable files in their appdir is stranded completely.

Here is the exact failure condition:

The user must be running either Linux or OS X and they should have a file with either the owner set to another user or the group set to one that they're not a member of.
(Assignee)

Updated

6 years ago
status-firefox15: --- → affected
status-firefox16: --- → affected
status-firefox17: --- → affected
status-firefox18: --- → affected
tracking-firefox16: ? → +
tracking-firefox17: --- → +
tracking-firefox18: --- → +
(Assignee)

Comment 34

6 years ago
Created attachment 659835 [details] [diff] [review]
Patch (v1)
Attachment #659835 - Flags: review?(robert.bugzilla)
Could we use a hotfix extension to get the affected users to the next version ?
(Assignee)

Comment 36

6 years ago
(In reply to comment #35)
> Could we use a hotfix extension to get the affected users to the next version ?

Did you see comment 32?  ;-)
(Assignee)

Comment 37

6 years ago
Filed bug 790065 to shut down updates.

Comment 38

6 years ago
BTW, did we ever try to repro on older versions of Firefox to see if this is a new thing or just newly discovered (aka, how far back should a hotfix go?)
(Assignee)

Comment 40

6 years ago
(In reply to [:Cww] from comment #38)
> BTW, did we ever try to repro on older versions of Firefox to see if this is
> a new thing or just newly discovered (aka, how far back should a hotfix go?)

The bug only happens with the new background updates code path which is the only place where we attempt to open a file in read-only mode using the ensure_open function.  The function itself had this bug since the patch for bug 505120 landed, but there were no callers which would trigger the bug in practice.
Blocks: 505120
Can we add a new QA test for this?
(Assignee)

Comment 42

6 years ago
(In reply to Al Billings [:abillings] from comment #41)
> Can we add a new QA test for this?

We must, yes.
(Assignee)

Comment 43

6 years ago
Bug 790096 tracks the creation of a hotfix add-on to mitigate this issue for the users affected by it.
Additional notes from cbeard in an email:

"Here's the Xfinity installer that did this.  Note that it now has an "expired certificate" that it didn't at the time, I think it was caught up in the recent cert invalidations although I'm pretty sure that's not at all related.  

It came from the Xfinity web site during the self-install process, although I can't find the link rich tnow

Thanks for digging in"

QA has this xfinity installer (3.4 MB) to share if people want it.  Just ping marcia, myself, or juanb, (or cbeard of course), and we'll email to whoever on the side.  

or i could attach it here if thats the right thing to do. (.pkg file type)
(Assignee)

Comment 45

6 years ago
Created attachment 659899 [details] [diff] [review]
Patch (v1)

Fixed a compilation problem on Windows.
Attachment #659835 - Attachment is obsolete: true
Attachment #659835 - Flags: review?(robert.bugzilla)
Attachment #659899 - Flags: review?(robert.bugzilla)
(Assignee)

Comment 47

6 years ago
(In reply to Ehsan Akhgari [:ehsan] from comment #46)
> New try push: https://tbpl.mozilla.org/?tree=Try&rev=73a7eac4b2d9

Scratch that! https://tbpl.mozilla.org/?tree=Try&rev=41aa07c28f41

Comment 48

6 years ago
Try run for dde9f3374fe9 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=dde9f3374fe9
Results (out of 22 total builds):
    exception: 9
    success: 11
    failure: 2
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-dde9f3374fe9

Comment 49

6 years ago
Try run for 73a7eac4b2d9 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=73a7eac4b2d9
Results (out of 8 total builds):
    exception: 8
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-73a7eac4b2d9
Comment on attachment 659899 [details] [diff] [review]
Patch (v1)

One of the goals with bgupdates was to fallback to the original update method whenever a bgupdate failed. Could this be made to fallback to the original method? If so, another bug would be the place to do it so it doesn't hold this up.
Attachment #659899 - Flags: review?(robert.bugzilla) → review+
(Assignee)

Comment 51

6 years ago
(In reply to Robert Strong [:rstrong] (do not email) from comment #50)
> Comment on attachment 659899 [details] [diff] [review]
> Patch (v1)
> 
> One of the goals with bgupdates was to fallback to the original update
> method whenever a bgupdate failed. Could this be made to fallback to the
> original method? If so, another bug would be the place to do it so it
> doesn't hold this up.

Agreed.  I didn't have enough time today to investigate why the fallback does not happen, but I can do that tomorrow.  I'll proceed to land this patch regardless.
(Assignee)

Comment 52

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/e3b1711e1aca
Target Milestone: --- → mozilla18
(Assignee)

Comment 53

6 years ago
Comment on attachment 659899 [details] [diff] [review]
Patch (v1)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 307181
User impact if declined: updates will break for a number of users running OS X or Linux.  See the bug for more details.
Testing completed (on m-c, etc.): Locally.
Risk to taking this patch (and alternatives if risky): The patch is not very risky, and it really makes sense.  Arguably I should have done this when I was working on bug 307181 had I known about the side-effects of calling ensure_open...
String or UUID changes made by this patch: None.

I'm also asking for release approval in case we decide to chemspill.
Attachment #659899 - Flags: approval-mozilla-release?
Attachment #659899 - Flags: approval-mozilla-beta?
Attachment #659899 - Flags: approval-mozilla-aurora?
Would be great if we can get an automated test for it.
Flags: in-testsuite?
https://hg.mozilla.org/mozilla-central/rev/e3b1711e1aca
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 56

6 years ago
(In reply to Henrik Skupin (:whimboo) from comment #54)
> Would be great if we can get an automated test for it.

Testing this on our servers will not be very easy, since we would need to add files to the tree who are owned by someone else, and you can only create such files if you're not root.
(Assignee)

Comment 57

6 years ago
s/not root/root/.  :-)

Updated

6 years ago
status-firefox18: affected → fixed
Comment on attachment 659899 [details] [diff] [review]
Patch (v1)

[Triage Comment]
Approving for Aurora/Beta - we want these to land on those branches regardless of the 15.0.2 or add-on hotfix situation.
Attachment #659899 - Flags: approval-mozilla-beta?
Attachment #659899 - Flags: approval-mozilla-beta+
Attachment #659899 - Flags: approval-mozilla-aurora?
Attachment #659899 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 59

6 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/ccdc7ee38db8
https://hg.mozilla.org/releases/mozilla-beta/rev/bc444c34d7de
status-firefox16: affected → fixed
status-firefox17: affected → fixed
Ben, can you please elaborate on your test in comment 26? Is the foo.xml an empty file? Does the searchplugins folder have to be owned by root or just the xml file?

Juan, once Ben clarifies the test can you please draft a MozTrap test and add it to the Firefox Desktop Regressions test suite? We'll need to make sure we spotcheck for this manually until we have automation in place.
Flags: in-moztrap?(jbecerra)
(Assignee)

Comment 61

6 years ago
(In reply to comment #60)
> Ben, can you please elaborate on your test in comment 26? Is the foo.xml an
> empty file?

It can be any file, empty or not, doesn't matter.

> Does the searchplugins folder have to be owned by root or just the
> xml file?

The searchplugins also does not have any significance, you can put the file anywhere in the installation directory.
I've gone ahead and added a draft testcase to MozTrap:
https://moztrap.mozilla.org/manage/cases/_detail/6454/

Can someone please review it and let me know if there are any gaps in the test?
Flags: in-moztrap?(jbecerra) → in-moztrap+
(Assignee)

Comment 63

6 years ago
(In reply to comment #62)
> I've gone ahead and added a draft testcase to MozTrap:
> https://moztrap.mozilla.org/manage/cases/_detail/6454/
> 
> Can someone please review it and let me know if there are any gaps in the test?

It would probably be a good idea to test the group ownership as well.

Updated

6 years ago
tracking-firefox15: ? → -
Comment on attachment 659899 [details] [diff] [review]
Patch (v1)

[Triage Comment]
We've discussed as a group, and this fix will first land in FF16.0 given the very small affected population.
Attachment #659899 - Flags: approval-mozilla-release? → approval-mozilla-release-
Assigning to myself to verify with tomorrow's builds.
QA Contact: anthony.s.hughes
(In reply to Ehsan Akhgari [:ehsan] from comment #56)
> (In reply to Henrik Skupin (:whimboo) from comment #54)
> > Would be great if we can get an automated test for it.
> 
> Testing this on our servers will not be very easy, since we would need to
> add files to the tree who are owned by someone else, and you can only create
> such files if you're root.

Hm, why does the file need another owner or group? Looking at the patch the only thing we are doing now is to check that the file hasn't been opened in read-only mode. Or is the read-only mode a fallback if we can't open in writable mode?
(Assignee)

Comment 67

6 years ago
(In reply to comment #66)
> (In reply to Ehsan Akhgari [:ehsan] from comment #56)
> > (In reply to Henrik Skupin (:whimboo) from comment #54)
> > > Would be great if we can get an automated test for it.
> > 
> > Testing this on our servers will not be very easy, since we would need to
> > add files to the tree who are owned by someone else, and you can only create
> > such files if you're root.
> 
> Hm, why does the file need another owner or group? Looking at the patch the
> only thing we are doing now is to check that the file hasn't been opened in
> read-only mode. Or is the read-only mode a fallback if we can't open in
> writable mode?

The bug happened when we tried to chmod a file owned by somebody else, which is a thing that only root gets to do.  This was happening as we were opening files in the installation directory as read-only in order to read and copy them elsewhere.  That is why the fix changes the read-only mode, but the key part here is avoiding the chmod call.
Oh, ok. So I don't see a way how to run such a test with Mozmill. We would have the same issue. On our systems we run in admin mode but it's not the case for other machines. Also we do not have any OS integration points yet to manage user accounts and so on. Probably we can automate that in the future if nothing else popped up. For now it looks like to be a manual test.
Flags: in-testsuite?
Flags: in-testsuite-
Flags: in-qa-testsuite-
Reproduce in Linux with Firefox 15.0 with the following steps:

1. Download and extract Firefox 15.0
2. Open terminal and cd to the firefox/searchplugins folder
3. Run command: touch foo.xml
4. Run command: sudo chown root:root foo.xml
5. Start Firefox and check for updates through the About dialog
> Download completes
> "update failed" appears in the dialog
> A link is provided to download the new version

I was going to verify this on Nightly, Aurora, and Beta but realized that this landed yesterday. I'm assuming I can't verify this until we have updates for today's builds (ie. tomorrow's builds come available). Is this correct?
(Assignee)

Comment 70

6 years ago
(In reply to comment #69)
> Reproduce in Linux with Firefox 15.0 with the following steps:
> 
> 1. Download and extract Firefox 15.0
> 2. Open terminal and cd to the firefox/searchplugins folder
> 3. Run command: touch foo.xml
> 4. Run command: sudo chown root:root foo.xml
> 5. Start Firefox and check for updates through the About dialog
> > Download completes
> > "update failed" appears in the dialog
> > A link is provided to download the new version
> 
> I was going to verify this on Nightly, Aurora, and Beta but realized that this
> landed yesterday. I'm assuming I can't verify this until we have updates for
> today's builds (ie. tomorrow's builds come available). Is this correct?

While we can simulate having updates by specifying an update override URL, let's not do that and wait for real updates.
(In reply to Ehsan Akhgari [:ehsan] from comment #70)
> While we can simulate having updates by specifying an update override URL,
> let's not do that and wait for real updates.

Agreed. I'll verify this for Aurora and Nightly using today's builds tomorrow. For Beta this will have to wait until 16.0b4 updates are available next week.
Verified fixed with:
 * 2012-09-12 Firefox 18.0a1 
 * 2012-09-12 Firefox 17.0a2

Both builds found and installed updates to their respective 2012-09-13 builds without any issues. As stated in comment 71, verification for Firefox 16 will need to wait until next week when we have 16.0b4 updates.
Status: RESOLVED → VERIFIED
status-firefox17: fixed → verified
status-firefox18: fixed → verified
(Reporter)

Comment 73

6 years ago
Does this mean that affected users (including myself) will be fixed by the update?  I might be missing something, but it would seem that I will still be stuck. Do we have another solution for people in this boat?
(In reply to Chris Beard from comment #73)
> Does this mean that affected users (including myself) will be fixed by the
> update?  I might be missing something, but it would seem that I will still
> be stuck. Do we have another solution for people in this boat?

While users stuck on Firefox 15.0 will not technically be fixed until they update to 16.0 in a few weeks (unless we do a 15.0.2), there is a workaround to get updates working again. Simply set app.update.stage.enabled to false in about:config and check for updates.

Note that we are working on a hotfix (currently in QA -- see bug 790096) which basically does this automagically. Once deployed, users on broken builds will have the pref flipped automatically and unprompted. At which point, their next manual or automatic update check should succeed.

Note that flipping this pref effectively disables background updates. We've re-enabled background updates in fixed builds by renaming the pref (see bug 790453).

Hopefully this answers your question, Chris. If not, maybe someone else can articulate the situation better than I.
(Reporter)

Comment 75

6 years ago
Great, thanks Anthony.

Comment 76

6 years ago
There's actually a much easier workaround: just reinstall Firefox (delete the Application and drag in a new one). All the permissions will be correct and updates should work going forward.
Verified fixed for Beta using Firefox 16.0b3 -> 16.0b4 updates on betatest channel.
status-firefox16: fixed → verified
(Assignee)

Updated

6 years ago
Duplicate of this bug: 803192
You need to log in before you can comment on or make changes to this bug.