890770 - app.update.silent disables notification to manually install for users that are unable to apply an update

Status: RESOLVED WORKSFORME

(Toolkit :: Application Update, defect)

Description

[Jason]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

This is a work environment with the following specifications:

--Windows 7 Professional machines
--Limited user accounts, with UAC turned on, with no installation privileges
--Mozilla Maintenance Service is installed and enabled
--Firefox installed in C:\Program Files\Mozilla Firefox, not in the user's local roaming directory
--Using Firefox 21 to try to update to Firefox 22

The following Firefox relevant preferences are set:

app.update.auto = true
app.update.enabled = true
app.update.service.enabled = true
app.update.mode = 0
app.update.silent = true


Actual results:

Firefox never updates with this configuration.  Even when app.update.interval is set to a low value to frequently check for updates, Firefox still never updates.

However, with the exact same configuration EXCEPT app.update.silent being set to "false," the user is at least periodically given a prompt to update the program.  So, it seems that app.update.silent disables updates entirely.


Expected results:

Ideally, app.update.silent would be set to "true" in order to suppress the updates prompts, and the program would automatically and silently update in the background.  Then, the next time the user closed and opened his/her browser, Firefox would be updated to the updated version.

Comment 2

[hartnegg]

The update with using the system service happens only when the user clicks on one of the update notifiers. Setting update to silent disables these notifiers.

When the update is set to automatic, and silent, and to use the service, it should skip displaying the notifiers, and behave as if the user had clicked.

Also it must check if the service is actually installed and functional. This is just being developed for the update through help/about, see
https://bugzilla.mozilla.org/show_bug.cgi?id=711475

Comment 4

[Jason]

Robert Strong, I am reading your revised summary, and I think I am unclear about its intent.

If you are implying that app.update.silent disabling notifications is the bug, I think I would technically disagree. This preference *should* disable update notifications; that is the point of the preference, and it already is doing that much very well. However, it should not disable automatic updating using the system service, which is -- I believe -- the actual issue. Yes, because currently updating requires users to respond to a notification, and the silent preference turns those notifications off, then auto updating no longer works, but I see that more as a symptom of the current updating system than as an intended feature.

In other words, I do not think the fact that the app.update.silent preference disablies manual notifications is an issue at all, since displaying notifications would make updating inherently non-silent.  This is not the way I interpret your revised summary. Of course, I could be misinterpreting your intent or misunderstanding the actual technical issues involved with silent automatic updating.

Comment 5

[Robert Strong (they/them - no direct email)]

Jason, what you are asking for is already covered by bug 711475 but the other issue of users not getting some form of notification (likely once per version as we should be doing now for this case when it isn't set to silent) when this preference is set and they don't have the service to update the user. Also keep in mind that disabling updates through the UI will prevent the notification and this preference is for applying updates silently and not for the case whatever reason the user has to perform steps to update. Another point is that there are OS's where we don't have a service to be able to apply an update. So, the choices are this bug could be duped to bug 711475 or it can be left open and used to handle the cases I just outlined.

Comment 6

[Jason]

Robert, that is not my interpretation of bug 711475.  In Comment 48 and Comment 51 of bug 711475, that bug seems to apply solely to the About Firefox dialog box, not the implications of setting the app.update.silent preference to "true."  Is that not your understanding?

My sole intention of bug 890770 was to address the situation in Microsoft Windows-based machines in which the user has limited-access privileges to the system, app.update.auto is set to "true," app.update.enabled is set to "true," app.update.service.enabled is set to "true," app.update.silent is set to "true," and the Mozilla Maintenance service is not automatically updating the program with no prompts.

Is my understanding of app.update.silent incorrect?  Is it *supposed* to disable background updating?  My understanding is that app.update.silent is acting *exactly* as it should right now, minus the fact that the service is not performing updates without user interaction.

Sorry about all the questions, but I am very confused.

Comment 7

[Robert Strong (they/them - no direct email)]

(In reply to Jason from comment #6)
> Robert, that is not my interpretation of bug 711475.  In Comment 48 and
> Comment 51 of bug 711475, that bug seems to apply solely to the About
> Firefox dialog box, not the implications of setting the app.update.silent
> preference to "true."  Is that not your understanding?
It definitely isn't. That bug is about the ability to apply updates as a user and I am fairly certain that the about UI (I wrote the majority of code for both of them) mentioned in those comments are in regards to differentiating between a UI update and an update with no UI. I can gaurantee that the fix for bug 711475 won't land without at the very least providing the ability to apply an update as a limited user with or without any UI though whether it will apply to installs outside of program files has yet to be determined.
 
> My sole intention of bug 890770 was to address the situation in Microsoft
> Windows-based machines in which the user has limited-access privileges to
> the system, app.update.auto is set to "true," app.update.enabled is set to
> "true," app.update.service.enabled is set to "true," app.update.silent is
> set to "true," and the Mozilla Maintenance service is not automatically
> updating the program with no prompts.
So, the Mozilla Maintenance service is not updating limited users is bug 711475. The remainder of your requirements in the above paragraph "should just work" as is with no additional code after bug 711475 is fixed. Without bug 711475 fixed the notification is not shown at all due to a bug which I would like to use this bug for. If you would prefer I can dupe this bug to bug 711475 and file a new bug for the cases I outlined in comment #5.

> Is my understanding of app.update.silent incorrect?  Is it *supposed* to
> disable background updating?  My understanding is that app.update.silent is
> acting *exactly* as it should right now, minus the fact that the service is
> not performing updates without user interaction.
No and it doesn't for the case where the user *can* perform a background update. Bug 711475 will make it so the vast majority of Windows users that currently *can't* perform a background update will be able to as long as they have the maintenance service installed.

> Sorry about all the questions, but I am very confused.
No problem. It is understandable since it is anything but a simple process and there are many different paths that can be taken depending on many different conditions.

Comment 8

[Robert Strong (they/them - no direct email)]

(In reply to Robert Strong [:rstrong] (do not email) from comment #7)
> (In reply to Jason from comment #6)
> > Robert, that is not my interpretation of bug 711475.  In Comment 48 and
> > Comment 51 of bug 711475, that bug seems to apply solely to the About
> > Firefox dialog box, not the implications of setting the app.update.silent
> > preference to "true."  Is that not your understanding?
> It definitely isn't. That bug is about the ability to apply updates as a
> user and I am fairly certain that the about UI (I wrote the majority of code
> for both of them) mentioned in those comments are in regards to
> differentiating between a UI update and an update with no UI.
Left out a couple of words.
"That bug is about the ability to apply updates as a user that is unable to perform an update due to not having write access"...

Comment 9

[hartnegg]

It seems that we are talking about different things.
Silent and 'no questions asked' is not necessarily the same.

The confusion, and the bugs, may be caused by the fact that the update notifier is not just a notifier, it is also always a question. And I think that this is not always justified, because 'app.update.auto=true' does not sound like 'ask', it sounds more like automatically do it.

There are four possible combinations for the options 
'app.update.auto' and 'app.update.silent'. 
What should Firefox do in these four cases?
Does it currently do what the options say? I think not! 
Here is my interpretation of what the options say.

For the following I assume that Firefox was installed by admin, the current user has no right to write there, the service is active, and these options are set:
app.update.enabled = true
app.update.service.enabled = true

Case 1: auto=true, silent=true
For me this clearly sound like automatic silent updates, no questions asked, no notifier shown.
The poster for this bug seems to want this behaviour, and currently cannot get it. I also think that this behaviour would be useful in many cases.

Case 2: auto=false, silent=false
This should show the update notifier, and ask if the user wants to update.
Currently we get this behaviour with auto=true, silent=false (case #1), but I would not call this update-behaviour "automatic", I regard this a bug, and think that this bug should be about this.

Case 3: auto=true, silent=false
These settings request to show the update notifier, but not to ask, only inform. So it needs the notifier as pure notifier, without the question.
I don't think that this combination makes much sense, because there is already the "What's new" page, controlled by browser.startup.homepage_override.mstone, which has the advantage to inform *all* users, not just the current one.

Case 4: auto=false, silent=true
In this case the only way to get an update is to go to help/about (and even there it should not run automatically, it should ask).
This currently does not work, which is handled by bug 711475, as said in this comment:
https://bugzilla.mozilla.org/show_bug.cgi?id=711475#c48

What if the service is not installed? then it depends on the rights of the user. If the user has the required rights, then the behaviour should be the same. Otherwise there are cases in which Firefox cannot perform the requested function, and in these cases it should inform the user and offer to enter an admin password.

Comment 10

[Steffen Wilberg]

As I said in bug 711475, I found that background updates already work for me (on a limited user account on Windows, in the program files directory, with the service installed). I got an update dialog popped up asking me to restart (or download and then restart, not sure about that).

That's why I said in bug 711475 that I'd like to concentrate on the other entry point, which is manually checking and applying updates, which doesn't work yet. It's easier to work on narrow bugs.

From the comments in this bug, it seems that automatic updates *do work* with limited user accounts *unless* the silent pref is set to true. We still need to confirm this and diagnose further.

So, to better diagnose this bug, an update log would be quite handy.
It would be lovely if you could install Nightly (http://nightly.mozilla.org/, or perhaps one that is a day or 2 old to get updates immediately, like http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-07-28-03-02-04-mozilla-central/firefox-25.0a1.en-US.win32.installer.exe).
Set the pref app.update.log to true (and app.update.interval to a low value), and copy the log output from the Browser Console. Click "Add an attachment" at the top of this bug and attach the log.

Comment 11

[hartnegg]

Attachment: firefox update-log.txt

result of app.update.log=true with app.update.enabled=true, app.update.auto=true, app.update.service.enabled=true, app.update.silent=true

Comment 12

[Steffen Wilberg]

Excellent, thanks!

The key lines are:
[17:22:17.129] AUS:SVC gCanApplyUpdates - windowsVersion = 5.1
[17:22:17.130] AUS:SVC gCanApplyUpdates - testing write access C:\Programme\Nightly\update.test

[17:22:17.131] AUS:SVC gCanApplyUpdates - unable to apply updates. Exception: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.create]"  nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)"  location: "JS frame :: resource://gre/components/nsUpdateService.js :: aus_gCanApplyUpdates :: line 580"  data: no]

So this is the exact same code path - gCanApplyUpdates - that I'm patching in bug 711475. I'm disabling those write checks if the service is installed and enabled.
So fixing that will fixing your problem.


The remaining bug here is, per the new subject, that there's no notification when the user doesn't have write access and the service is not installed or is installed but disabled.

Comment 13

[Robert Strong (they/them - no direct email)]

Thanks Steffen for verifying my conclusions... it is much appreciated!

Comment 14

[Mario]

I'm also seeing this behavior:

Case 1: auto=true, silent=true
For me this clearly sound like automatic silent updates, no questions asked, no notifier shown.

As Jason (original poster), I have this issue as well. I'm expecting Firefox to update automatically silently (same way Chrome does) however, if the silent=true, this is not happening.

The only way I can seem to update Firefox with a standard (not admin) account on Windows, is to set the auto=true and silent=false. When I do this, I do see a little notification show up (which seems to be very short lived) letting me know that there is an update waiting to be downloaded and installed. Knowing my users, 99% of them will just ignore this and never update FireFox.

Comment 15

[Jason]

Can anyone else confirm this is fixed?

It *seems* to have correctly worked for me on a few "in the wild" PCs, so I was wondering if anyone else has tested to see if it is fixed for them, too.  So, this may very well be resolved.

Comment 16

[thpierre]

Hello,
I tested the silent installation successfully for Firefox 26 and 27. However, with an administrator account on Windows ... I still have to test with an normal account.

Comment 17

[thpierre]

The silent update went fine also with a standard account. The bug seem really resolved.

Comment 18

[Robert Strong (they/them - no direct email)]

Per comment 15, 16, and 17 resolving as wfm