1030911 - If update fails (because of a limited account) the user should be directed to SUMO

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Gregory Szorc [:gps]]

Another report from Paul. I think this one might be proper behavior. But I want a bug to track it just to be sure.

On Win Xp you can't perform the update via Hotfix from a Limited Account if Firefox was installed under Program Files folder. Log error entry:
[1403787295697,50,"Could not open install directory for writing: [Exception... \"Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFileOutputStream.init]\"  nsresult: \"0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)\"  location: \"JS frame :: resource://firefox-hotfix/update.jsm :: UpgradeManager.prototype._isInstallPathWritable :: line 1779\"  data: no]"]
[1403787295697,50,"Install path is not writable."]

Comment 1

[Benjamin Smedberg]

What's the user experience? We want to end up showing them the SUMO page in this case, right?

Comment 2

[Gregory Szorc [:gps]]

I forgot to transfer my comment from the etherpad.

This error message in the logs is expected for the scenario described (permissions issue on XP). What is also expected is for the hotfix to uninstall itself. Paul needs to verify that happens.

There is no code for going to SUMO because I was not aware of that requirement. Personally, if the hotfix uninstalls itself because of this, my opinion is we can assess where we stand after a month or two. If enough users are impacted by this, we copy the hotfix, add a SUMO page load etc, and release a new version of the hotfix. Actually, I'd be surprised if we don't end up releasing a follow-up hotfix to address the corner cases this hotfix uncovers.

Comment 3

[Georg Fritzsche [:gfritzsche]]

Opening a SUMO page sounds like relatively small effort, so we should probably not bet on a follow-up hotfix for that.

Comment 4

[Paul Silaghi, QA [:pauly]]

(In reply to Gregory Szorc [:gps] from comment #2)
> This error message in the logs is expected for the scenario described
> (permissions issue on XP). What is also expected is for the hotfix to
> uninstall itself. Paul needs to verify that happens.
After 2 hours of waiting, it didn't uninstall. Using the same limited account, on a folder with permissions in the user profile, the hotfix was gone in ~ 20 min from the Addon Manager. But the hotfix-update folder in the Firefox profile doesn't seem to get removed. But this might be another issue. I see this behavior also on Win 7, regular/admin accounts. Or could the hotfix-update folder deletion just take more time after the addon is gone from the Addon Manager?

Comment 5

[Georg Fritzsche [:gfritzsche]]

(In reply to Paul Silaghi, QA [:pauly] from comment #4)
> But the hotfix-update folder in the
> Firefox profile doesn't seem to get removed. But this might be another
> issue. I see this behavior also on Win 7, regular/admin accounts.

Are you talking about the addon folder in <profile-dir>/extensions?

Comment 6

[Paul Silaghi, QA [:pauly]]

Yes, but it's not in /extensions:
c:\Users\paul.silaghi\AppData\Roaming\Mozilla\Firefox\Profiles\8wwxpr9i.16\hotfix-update

Comment 7

[Georg Fritzsche [:gfritzsche]]

That one should be removed [1] - from the above comments it sounds like it never is for you?

[1] https://bitbucket.org/indygreg/firefox-hotfixes/src/1aecc14ef0a61f2ff9d648476119b3dc4e633343/v20140527.01/resource/update.jsm?at=default#cl-705

Comment 8

[Paul Silaghi, QA [:pauly]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #7)
> That one should be removed [1] - from the above comments it sounds like it
> never is for you?
Yes, but I'm a little confused, since I remember I tested this and it was ok.

Comment 9

[Benjamin Smedberg]

Going to SUMO was a specified behavior from bug 994882 comment 26. We must have that behavior. If the installer fails, we open https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/failed-update

Removal of the hotfix-update directory is less important, although we should understand it. But it should be filed as a separate bug.

Comment 10

[Paul Silaghi, QA [:pauly]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> Removal of the hotfix-update directory is less important, although we should
> understand it. But it should be filed as a separate bug.
bug 1031340

Comment 11

[Gregory Szorc [:gps]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> Going to SUMO was a specified behavior from bug 994882 comment 26. We must
> have that behavior. If the installer fails, we open
> https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/failed-update

Bah - I missed that comment. Will address this.

Comment 12

[Gregory Szorc [:gps]]

Attachment: Open SUMO when auto upgrade fails

Comment 13

[Gregory Szorc [:gps]]

https://hg.mozilla.org/releases/firefox-hotfixes/rev/a89c8a9ffe4b

Comment 14

[Paul Silaghi, QA [:pauly]]

1. Now, in case of a normal update flow on admin accounts, after installing the addon, the update failed SUMO page shows up and the addon is instantly uninstalled. After restart, the update to FF 30 is successfully made though.
2. The SUMO tab is not focused.

Comment 15

[Paul Silaghi, QA [:pauly]]

Tested with https://people.mozilla.org/~gszorc/hotfix-v20140527.01-qa.xpi

Comment 16

[Gregory Szorc [:gps]]

I'm able to reproduce. I'm pretty sure bug 1030856 is to blame. Will comment there.

Comment 17

[Gregory Szorc [:gps]]

The update to bug 1030856 appears to fix this. I hope Paul sees the same result!

https://people.mozilla.org/~gszorc/hotfix-v20140527.01-qa.xpi has been updated. Will be asking for a new signed XPI shortly.

Comment 18

[Paul Silaghi, QA [:pauly]]

Tested on FF 10, 15.0.1, 27.0.1 Win XP.
Verified fixed.
Note that the update failed SUMO tab loads in background, so the user may not notice it and understand what the problem is.