Another report from Paul. In a non-admin user account, if FF is installed in a location outside of C:\Program Files (x86)\, the update is performed even if choosing No at the UAC prompt. This is not reproducible if FF is installed in C:\Program Files (x86)\
Paul tested on Win 7 x64, FF 10.0.1, 17.0.1, 20, 28
I don't think this is a bug. I think the only reason we need to request UAC is because we need admin privs to write to Program Files. But can you be specific about what the exact alternate directory is? Perhaps rstrong can clarify the desired behavior.
This is intentional. We only elevate during update when it is necessary to elevate to avoid having the additional step of clicking the button in the UAC dialog.
So if there is a bug here, it's that we're showing the UAC prompt at all? That seems minor enough not to block.
Comment #3 is for app updating. For the install / upgrade case using the installer we do request elevation if we determine elevating to an an admin is possible (e.g. member of admin, UAC turned on, etc.). This allows the installer to install into Program Files by default, etc. if the user does elevate and to install into a user specific location if they don't elevate.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > But can you be specific about what the exact alternate directory is? "c:\Mozilla Firefox 20", so it's not necessary to be in the user profile folder (c:\Users\username) (In reply to Benjamin Smedberg [:bsmedberg] from comment #4) > So if there is a bug here, it's that we're showing the UAC prompt at all? > That seems minor enough not to block. Pressing "NO" to actually be "YES" looks pretty confusing to me.
I can see it being confusing when taking the time to think about it but we have yet to have a user state it is confusing over the many years that it has been like this likely because they don't think about it. This also allows us to successfully install in more cases since we can successfully install when the user chooses not to elevate.
It definitely sounds like the right behavior per what we discussed in bug 1014187 & bug 1014194. Please re-open if anyone thinks there is an issue here we need to resolve.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.