There is an edge case where an update failure doorhanger can be displayed when it really should not be. These are the required conditions to reproduce the problem:

• Update is disabled by enterprise policy
• app.update.log = true
• The permissions are on the update directory are wrong such that it cannot be written to and the permissions cannot be fixed without elevating
• The Mozilla Maintenance Service is not available, so the permissions on the directory absolutely cannot be fixed

In this situation, the UpdateService._logStatus() function (here) retrieves some data about the current status of update, in the process discovers that the update directory is not writable, tries to fix the permissions, fails, and displays an update failure doorhanger. The doorhanger really should never be displayed when update is disabled by policy.

In addition to this undesirable behavior, this also has the effect of making it very hard for me to debug Bug 1599590, where this exact situation seems to be happening, but with app.update.log = false. I can't seem to reproduce the problem, and when I look at the reporter's logging, I just see the bug described above, which effectively masks the bug that they see normally, presumably because gUpdateDirPermissionFixAttempted prevents permissions from being fixed a second time. They seem to have found a workaround to prevent the doorhanger, so the situation seems to be ok for that user, for now.

https://hg.mozilla.org/mozilla-central/rev/5ae122742f07