Closed Bug 719684 Opened 9 years ago Closed 9 years ago

Poor user experience when attempting to install desktop add-on

Categories

(Firefox for Android Graveyard :: General, defect)

11 Branch
ARM
Android
defect
Not set
normal

Tracking

(firefox11 affected, firefox12 affected, firefox13 verified)

VERIFIED FIXED
Firefox 13
Tracking Status
firefox11 --- affected
firefox12 --- affected
firefox13 --- verified

People

(Reporter: samth, Assigned: mbrubeck)

References

Details

(Whiteboard: [has patch])

Attachments

(1 file)

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
tracking-fennec: --- → ?
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]
Attached patch patchSplinter Review
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+
Blocks: 726863
Blocks: 726865
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?
https://hg.mozilla.org/mozilla-central/rev/845f215b717a
Status: ASSIGNED → RESOLVED
Closed: 9 years ago9 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
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.