Closed Bug 1511165 Opened 1 year ago Closed 1 year ago
about:welcome addon card on windows says "addon name"
see attached image. The raw data I get from the attribution service does have the proper name. Clicking the download button downloads the correct extension.
Maybe because of bug 1511156 ?
(In reply to Ursula Sarracini (:ursula) from comment #1) > Maybe because of bug 1511156 ? I thought that at first, but the download button works fine. Bug 1511156 affects the extension id in the attribution data, which we use in an API call to AMO to retrieve the rest of the data, which includes the extension name, download link, etc. The data retrieved via the AMO API is not encoded. about:welcome should also be a little more resilient. It currently fails so show anything if it cannot get the addon data. I'm not clear if that is intentional. I guess from a user perspective its fine, but it threw me through a loop while trying to figure out what was happening.
(In reply to Shane Caraveo (:mixedpuppy) from comment #2) > I thought that at first, but the download button works fine. I mean the "add extension" button as shown in the screenshot.
Maybe it's a problem with l10n... if getting the addon name fails it should return null, not "addon-name" so that's bizarre. I'll take a look.
Can we run some tests to identify how often this scenario occurs? It's important to understand if it's just an edge case or something more common. Anyhow, when we are not able to load the extension name, I suggest using something more neutral like 'Now let's get your extension.' NI Meridel on the bug to confirm the new string.
(In reply to Shane Caraveo (:mixedpuppy) from comment #3) > (In reply to Shane Caraveo (:mixedpuppy) from comment #2) > > > I thought that at first, but the download button works fine. > > I mean the "add extension" button as shown in the screenshot. Addon name  and addon install url  are fetched independently of each other so it's not unlikely that one of them fails, in this case the name.  https://github.com/mozilla/activity-stream/blob/608aef966d0cf4f59dda623c50602530dc2cc623/lib/OnboardingMessageProvider.jsm#L16  https://github.com/mozilla/activity-stream/blob/608aef966d0cf4f59dda623c50602530dc2cc623/lib/ASRouter.jsm#L809
Can you fix that so that a) we do not make multiple http calls to get data for a single extension, and b) we use the API rather than fetch? Are there any other API calls for other addon data items?
(In reply to emanuela [ux] [OOO 12/21 - 01/07] from comment #5) > Anyhow, when we are not able to load the extension name By my tests the extension name is in the data returned so this would be a bug somewhere in the activity stream code, not a lack of having access to the name.
If we cannot obtain the extension name for whatever reason, the string should be: Now let's get your extension. If we cannot obtain the theme name for whatever reason, the string should be: Now let's get your theme. (if it is possible to differentiate?)
I'm sorry to disagree. Given bug 1511173, I think that if we do not have all the data from the AMO api to indicate to the user what they are installing, we should not show the addon card at all. Even without that bug, I feel like having an install button where the user has no idea what is being installed is not good.
Aha, I see your point, and I concede. No add-ons card shown if we can't retrieve the AMO data.
Sounds good. If we were landing people back on an AMO product page the generic copy might be ok. But if the install is taking place right from about:welcome, better not to show if we can't fetch the data.
Thank you for adding extra context, Shane. I agree with you and Meridel.
Commit pushed to master at https://github.com/mozilla/activity-stream https://github.com/mozilla/activity-stream/commit/68cef93e3fba3dce03abfd2dd646ee6074a1693f Fix Bug 1511165 - about:welcome addon card on windows says "addon name" (#4589)
We will verify this bug as soon as it's possible to do so on Windows.
You need to log in before you can comment on or make changes to this bug.