Closed Bug 611793 Opened 9 years ago Closed 9 years ago

Addon restart system notification does not go away on restart

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set

Tracking

(fennec2.0+)

VERIFIED FIXED
Tracking Status
fennec 2.0+ ---

People

(Reporter: aakashd, Assigned: wesj)

References

Details

Attachments

(1 file, 1 obsolete file)

Build Id:
Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101111 Namoroka/4.0b8pre Fennec/4.0b3pre

Steps to Reproduce:
1. Go to addons.mozilla.org
2. Click "Add to Mobile" for any recommended add-on
3. Click on "Install" in the resulting dialog
4. Swipe to the left to open the controls sidebar
5. Click on the Add-ons Manager pane button
6. Click on the restart button
7. After fennec finishes restarting, swipe down from the top to open the system notification menu 

Actual Results:
The restart notification is still present

Expected Results:
The restart notification should not be present
tracking-fennec: --- → ?
Flags: in-litmus?(ayanshah62)
Assignee: nobody → wjohnston
Attached patch Patch v1 (obsolete) — Splinter Review
Removes all addon notifications if any installation is cancelled or if a restart is fired. Should fix this and Bug 611796. Since we aren't keeping track of notifications on an individual addon basis (yet?), this may result in strange circumstances occasionally. But for 99% of actions, I think this should be fine.

Cancelling an install after the addon is downloaded (or anytime for that matter) should fire an onInstallCancelled event I would think, but here:

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/XPIProvider.jsm#4918

it fires a onDownloadCancelled event instead, so we catch that there instead.
Attachment #490591 - Flags: review?(mark.finkle)
Blocks: 611796
Comment on attachment 490591 [details] [diff] [review]
Patch v1

>diff --git a/chrome/content/extensions.js b/chrome/content/extensions.js

>     let alerts = Cc["@mozilla.org/alerts-service;1"].getService(Ci.nsIAlertsService);
>     alerts.showAlertNotification(URI_GENERIC_ICON_XPINSTALL, strings.getString("alertAddons"),
>                                  aMessage, true, "", observer, "addons");
>-  }
>+  },
>+  hideAlerts: function ev_hideAlerts() {
>+#ifdef ANDROID
>+    let alertsService = Cc["@mozilla.org/alerts-service;1"].getService(Ci.nsIAlertsService);
>+    let progressListener = alertsService.QueryInterface(Ci.nsIAlertsProgressListener);
>+    progressListener.onCancel("addons");
>+#endif

Add a blank line between the methods.


>-    else
>+    else {
>+      ExtensionsView.hideAlerts();
>       return; // no need to show anything in this case

Hiding all addon alerts if everything goes OK might be a bit much, but like you said - we don't have individual control over that yet. Let's see how this works in general.
Attachment #490591 - Flags: review?(mark.finkle) → review+
tracking-fennec: ? → 2.0+
Attached patch Fix nitsSplinter Review
Attachment #490591 - Attachment is obsolete: true
Attachment #490742 - Flags: review+
Whiteboard: [checkin-needed]
pushed:
http://hg.mozilla.org/mobile-browser/rev/3fdb24e03e4b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [checkin-needed]
verified FIXED on build:
Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101116 Namoroka/4.0b8pre Fennec/4.0b3pre
Status: RESOLVED → VERIFIED
https://litmus.mozilla.org/show_test.cgi?id=13825
Flags: in-litmus?(ayanshah62) → in-litmus+
You need to log in before you can comment on or make changes to this bug.