Closed Bug 719684 Opened 9 years ago Closed 9 years ago
Poor user experience when attempting to install desktop add-on
Attempting to install an add-on from a web link does nothing. To reproduce, go to https://github.com/mozilla/pdf.js and click on the link for the Firefox xpi. You get a doorhanger prompt to allow Github to install add-ons. Tap allow. FF display s a message saying the addon is downloading. nothing further happens and the addon is not installed.
That's a desktop Firefox extension.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
In that case, it should say that the addon can't be installed. Silently doing nothing is a pretty bad user experience.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Confirmed. If you click on a link to an XPI, it asks you whether you want to allow that site to install addons or not, and then when you say yes, it says "addon downloading" as a mid-screen alert... and then nothing. Many people are bound to think that a Firefox extension is a Firefox extension, and try this - so we need a clear error message explaining why what they are trying to do doesn't work. Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: installing add-ons from web fails → Poor user experience when attempting to install desktop add-on
Just to be clear because I got nervous, I don't think we'll need l10n here. We have a "failed" string at the very least: http://mxr.mozilla.org/mozilla-central/source/mobile/android/locales/en-US/chrome/browser.properties#10 but ideally we'd use the desktop addon manager strings i think? http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties#61
Assignee: nobody → mbrubeck
tracking-fennec: ? → ---
Status: NEW → ASSIGNED
Whiteboard: [has patch]
This patch uses strings from toolkit's "extensions.properties" as suggested by Wes above. This will let us move this fix into Aurora without breaking string freeze. These strings are meant to be used in toolkit's extensions.xul and it's probably not ideal to reuse them in a different context like this. I can file a follow-up bug to add our own strings (like XUL Fennec). We should also file a follow-up bug to design and implement better UX for blocklisted, softblocked, and outdated add-ons.
Attachment #596853 - Flags: review?(mark.finkle)
Comment on attachment 596853 [details] [diff] [review] patch Please file the followup with a mobile specific string, using the XUL strings as a base.
Attachment #596853 - Flags: review?(mark.finkle) → review+
Comment on attachment 596853 [details] [diff] [review] patch [Approval Request Comment] User impact if declined: Silent failure when users try to install incompatible add-ons. Testing completed (on m-c, etc.): Pushed to inbound on 2/13. Risk to taking this patch (and alternatives if risky): Low-risk and mobile-only. Even if there is an uncaught bug in this code, it will just silently throw an exception and die. Worst-case, it could display the wrong error message when there is an error. String changes made by this patch: None.
Attachment #596853 - Flags: approval-mozilla-aurora?
Status: ASSIGNED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Comment on attachment 596853 [details] [diff] [review] patch [Triage Comment] Mobile only - approved for Aurora 12.
Attachment #596853 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
This issue seems to be fixed on the latest Nightly (2012-03-06). However when I load the page from comment #0, I see this: http://img406.imageshack.us/img406/420/device20120306170653.png Is it expected?
Cristian, that's bug 719685.
Thanks Sam. This issue doesn't occur anymore on the Nightly build. Closing bug as: Verified fixed on: Firefox 13.0a1 (2012-03-06) 20120306031101 http://hg.mozilla.org/mozilla-central/rev/7d0d1108a14e -- Device: HTC Desire OS: Android 2.2
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.