Closed Bug 1511165 Opened 1 year ago Closed 1 year ago

about:welcome addon card on windows says "addon name"

Categories

(Firefox :: Messaging System, defect, P2)

65 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 66
Iteration:
66.2 - Dec 24 - Jan 6
Tracking Status
firefox65 --- disabled
firefox66 --- verified

People

(Reporter: mixedpuppy, Assigned: andreio)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

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.
Iteration: --- → 66.1 - Dec 10-23
Priority: -- → P2
Assignee: nobody → andrei.br92
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.
Flags: needinfo?(mwalkington)
(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 [0] and addon install url [1] are fetched independently of each other so it's not unlikely that one of them fails, in this case the name.

[0] https://github.com/mozilla/activity-stream/blob/608aef966d0cf4f59dda623c50602530dc2cc623/lib/OnboardingMessageProvider.jsm#L16
[1] 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?
Flags: needinfo?(andrei.br92)
(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?)
Flags: needinfo?(mwalkington)
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.
Flags: needinfo?(mwalkington)
Flags: needinfo?(emanuela)
Aha, I see your point, and I concede. No add-ons card shown if we can't retrieve the AMO data.
Flags: needinfo?(mwalkington)
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.
Flags: needinfo?(emanuela)
Iteration: 66.1 - Dec 10-23 → 66.2 - Dec 24 - Jan 6
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)
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Flags: needinfo?(andrei.br92)
Blocks: 1517867
We will verify this bug as soon as it's possible to do so on Windows.

Is this something we need to uplift to Beta?

Flags: needinfo?(andrei.br92)

I would think not needed for beta 65 given that it'll be turned off for 65 with bug 1515411… yeah?

Yes, no uplift needed.

Flags: needinfo?(andrei.br92)

Verified using Nightly 66.0a1 (build 20190120213632) on Windows 10 x64 using multiple extensions, the issue is no longer reproducible. Attaching screenshot

Status: RESOLVED → VERIFIED
Attached image validated.png
Component: Activity Streams: Newtab → Messaging System
You need to log in before you can comment on or make changes to this bug.