719684 - Poor user experience when attempting to install desktop add-on

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Sam Tobin-Hochstadt [:samth]]

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.

Comment 1

[Aaron Train [:aaronmt]]

That's a desktop Firefox extension.

Comment 2

[Sam Tobin-Hochstadt [:samth]]

In that case, it should say that the addon can't be installed.  Silently doing nothing is a pretty bad user experience.

Comment 3

[Gervase Markham [:gerv]]

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

Comment 4

[Wesley Johnston (:wesj)]

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

Comment 5

[Matt Brubeck (:mbrubeck)]

Attachment: 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.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 596853 [details] [diff] [review]
patch

Please file the followup with a mobile specific string, using the XUL strings as a base.

Comment 7

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/845f215b717a

Comment 8

[Matt Brubeck (:mbrubeck)]

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.

Comment 9

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/845f215b717a

Comment 10

[Alex Keybl [:akeybl]]

Comment on attachment 596853 [details] [diff] [review]
patch

[Triage Comment]
Mobile only - approved for Aurora 12.

Comment 11

[Cristian Nicolae (:xti)]

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?

Comment 12

[Sam Tobin-Hochstadt [:samth]]

Cristian, that's bug 719685.

Comment 13

[Cristian Nicolae (:xti)]

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