Closed Bug 1600923 Opened 8 months ago Closed 4 months ago

move Thunderbird off remotely hosted discovery pane in about:addons

Categories

(Thunderbird :: Add-Ons: General, task, P1)

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 76.0

People

(Reporter: mkmelin, Assigned: sancus)

References

Details

Attachments

(1 file)

Bug 1337627 wants to remove support for the remove discovery pane in the addons-manager. Firefox moved it to in-content with json data fetched from AMO instead.

The discovery pane - extensions.webservice.discoverURL is currently something like https://services.addons.thunderbird.net/en-US/thunderbird/discovery/pane/68.3/Linux
... and we generally agree that's pretty awful.

The plan is to reuse what Firefox already implemented for add-ons listing. At least as at first we don't need the list to be too smart, as we don't have that many add-ons. We don't want to send the user off into the browser needlessly since then installation is then difficult.

We need

Summary: move Thunderbird off remotely hosted discovery pan in about:addons → move Thunderbird off remotely hosted discovery pane in about:addons

Bug 1337627 is now on autoland.

The ATN url in the above comment is functioning now. https://services.addons.mozilla.org/api/v4/discovery/?lang=en-US&edition=default

That is the AMO url. I guess you meant https://services.addons.thunderbird.net/api/v4/discovery/?lang=en-US&edition=default
There is one difference (at least) causing problems: the name on ATN is and object with all languages, but on AMO it's just the plain string (maybe for the given locale, I'm not sure). Could you change that?

Flags: needinfo?(sancus)

(In reply to Magnus Melin [:mkmelin] from comment #3)

That is the AMO url. I guess you meant https://services.addons.thunderbird.net/api/v4/discovery/?lang=en-US&edition=default
There is one difference (at least) causing problems: the name on ATN is and object with all languages, but on AMO it's just the plain string (maybe for the given locale, I'm not sure). Could you change that?

Will fix. This involves setting 'l10n_flat_input_output' on the v4 output, which it wasn't originally intended to have. Just as a note, this setting isn't present on the v5 API so it may change again in the future.

Assignee: nobody → sancus
Flags: needinfo?(sancus)

This is what I had for testing. Unclear if more is needed except for the server side change.

Server-side change is live, should be good to try again: https://services.addons.thunderbird.net/api/v4/discovery/?lang=en-US&edition=default

How is the list of add-ons determined? ATM it's only two. Can we make it a really long list? Basically all compatible with 68+

It's manually set in the admin panel. I was figuring we would use it like the recommended add-ons, so put 10-20 in there, rotated regularly. Putting every 68+ compatible add-on in there would require code changes I think and would just result in totally random recommendations from TB, no?

Actually, seems the description_text property (instead of description) is used so they do not get the description in the listing.

We could list them all in order of current number of users? If you have to go beyond the list, the add-on is not installable easily since you go outside of the Thunderbird add-on UI and into the browser instead.

Comment on attachment 9136436 [details] [diff] [review]
bug1600923_addon_disco.patch

Just adding the pref won't make it any worse. This is what it looks like now: https://pasteboard.co/J1wQFgb.png
With some more data and the description field fixed it should be even better.
Attachment #9136436 - Flags: review?(alessandro)
Comment on attachment 9136436 [details] [diff] [review]
bug1600923_addon_disco.patch

Review of attachment 9136436 [details] [diff] [review]:
-----------------------------------------------------------------

This pref allows pulling those recommended add-ons with the same style of Firefox, which is good.
We should definitely include the author, description, rating and number of users before shipping this.
Also, we should implement a link to go to the add-on page if the user needs to read more before installing it.
Attachment #9136436 - Flags: review?(alessandro) → review+

I'm not sure where the description_text field comes from, but I'll look into it.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/1f8b1a573fb2
use the API data for add-on discovery pane (about:addons). r=aleca

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED

I wonder why Firefox doesn't allow "clicking open" the description and such for add-ons you didn't yet install, but only does it for the ones you did install. That seems backwards...

I think once the data is aligned some more, we will get what Firefox displays. The part above may be because the data isn't sent out by the api ATM (?) - would have to investigate what AddonCard does... For Thunderbird we may want to change that.

Target Milestone: --- → Thunderbird 76.0

(In reply to Magnus Melin [:mkmelin] from comment #16)

I wonder why Firefox doesn't allow "clicking open" the description and such for add-ons you didn't yet install, but only does it for the ones you did install. That seems backwards...

The expanded card has controls and shows metadata of the installed add-on. Entries in the discovery pane don't have this information, so there is no point in offering an expand option.

True, the controls would not be useful. But is there a reason not to show the full description when you click on it? Also maybe the homepage link where you could find out more. To make an install decision, the one-liner description may not be enough and that's all you get now, even for Firefox.

Firefox's UI for this is indeed very strange. For example, the author name gets a link, but that link takes you to the add-on... not to the author's profile. And the add-on name is not a link. You'd think the add-on name would be where that link would be...

It's not clear to me why the author name links aren't working for us, either.

In reply to comment #18 and comment #19:

We tried to display extensions in a consistent way across the whole Firefox ecosystem, and the result of that is the "Universal Extension Card".

True, the controls would not be useful. But is there a reason not to show the full description when you click on it?

The descriptions are curated messages that are meant to succinctly describe the add-on and attrack users. By design, the cards have a fixed appearance. It is technically possible to make the card expand upon click, but that was not how it was designed (visual/UX).

Also maybe the homepage link where you could find out more. To make an install decision, the one-liner description may not be enough and that's all you get now, even for Firefox.

There is a link to the add-on listing for those who want to know more.

(In reply to Andrei Hajdukewycz [:sancus] from comment #19)

Firefox's UI for this is indeed very strange. For example, the author name gets a link, but that link takes you to the add-on... not to the author's profile. And the add-on name is not a link. You'd think the add-on name would be where that link would be...

That's a conscious decision. The author's profile page would be more consistent, but I imagined that most users who are more interested in information about the specific add-on, rather than the add-on author itself (the author profile has little information).

It's not clear to me why the author name links aren't working for us, either.

https://services.addons.thunderbird.net/api/v4/discovery/?lang=en-US&edition=default does not include an "authors" key with the "name" field under each addon.

Here is the wrapper around the API response: https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/toolkit/mozapps/extensions/content/aboutaddons.js#492-520
Part of the parsing is delegated to _parseAddon, implemented here: https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/toolkit/mozapps/extensions/internal/AddonRepository.jsm#580-663

Here is an example of an expected response, with all relevant fields highlighted: https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/toolkit/mozapps/extensions/test/browser/discovery/api_response.json#2-9,12,18-24,62,64-67,73-74

(In reply to Rob Wu [:robwu] from comment #20)

In reply to comment #18 and comment #19:
That's a conscious decision. The author's profile page would be more consistent, but I imagined that most users who are more interested in information about the specific add-on, rather than the add-on author itself (the author profile has little information).

Right I don't think the link is the strange part, the strange part to me is why the add-on name isn't the link. It's larger and currently has no links at all. So why not use it instead of the author name?

I think there are a lot of problems with this UI as a discovery mechanism for Thunderbird add-ons(it's very limited, you can't select different categories or anything like that, you get very limited information on the add-on, etc). In the case of Firefox that's not so bad because people can just go to AMO manually if they want, but that doesn't work well for Thunderbird because installing TB add-ons via browser is a complicated process with downloading files and importing them into the app.

So I think we need some kind of "If you want to browse more add-ons, go to ATN" link or button on this page that opens ATN in a tab in TB to solve that problem for us.

Here is an example of an expected response, with all relevant fields highlighted: https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/toolkit/mozapps/extensions/test/browser/discovery/api_response.json#2-9,12,18-24,62,64-67,73-74

Thanks, this is helpful. I realized after posting that that we were missing some stuff in the API code. Unfortunately these changes were made to AMO quite late, in April 2019, and there are many changes past ~Jan 2019 in the AMO codebase that are completely breaking for us. So I will be able to fix this but it will take some time to backport those patches and make sure they don't break anything on ATN.

(In reply to Andrei Hajdukewycz [:sancus] from comment #21)

(In reply to Rob Wu [:robwu] from comment #20)

In reply to comment #18 and comment #19:
That's a conscious decision. The author's profile page would be more consistent, but I imagined that most users who are more interested in information about the specific add-on, rather than the add-on author itself (the author profile has little information).

Right I don't think the link is the strange part, the strange part to me is why the add-on name isn't the link. It's larger and currently has no links at all. So why not use it instead of the author name?

Because that doesn't align with the design of universal extension cards.

I'm wondering why you're asking for this to be a link though, since you're also stating "doesn't work well for Thunderbird because installing TB add-ons via browser is a complicated process with downloading files and importing them into the app.".

I think there are a lot of problems with this UI as a discovery mechanism for Thunderbird add-ons(it's very limited, you can't select different categories or anything like that,

The old TNO from comment 0 shows only two things, addons and complete themes. If you want to reuse logic as much as possible but still sort by different categories, then you could update the template of the discovery page yourself (at https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/toolkit/mozapps/extensions/content/aboutaddons.html#298-312 ), and replace <recommended-addon-list></recommended-addon-list> with <recommended-addon-list type="extension"></recommended-addon-list> for extensions, and type="theme" for themes. This logic is used in Firefox to show recommendations under the Extensions list and under the Themes list, so it will probably stick around for the foreseeable future.

So I think we need some kind of "If you want to browse more add-ons, go to ATN" link or button on this page that opens ATN in a tab in TB to solve that problem for us.

There is a "Find more add-ons" button at the bottom of about:addons.

(In reply to Rob Wu [:robwu] from comment #22)

Because that doesn't align with the design of universal extension cards.

I have to admit, I don't think "it doesn't align with the design" is a good argument or an explanation for the design. I'm not necessarily asking for Firefox to change this. Obviously I have no influence over that. But this design feels very counter-intuitive to me. Always has.

I'm wondering why you're asking for this to be a link though, since you're also stating "doesn't work well for Thunderbird because installing TB add-ons via browser is a complicated process with downloading files and importing them into the app.".

Links in the discovery pane are OK, because we can make those open inside Thunderbird content tabs which have reasonable install behaviour. It's when you go to ATN manually outside of Thunderbird that it becomes a problem.

There is a "Find more add-ons" button at the bottom of about:addons.

Yeah, I totally forgot about that button, probably because you have to scroll down to get to it. I get why it's there, but I kinda wish it was at the top honestly. Or maybe at the top of the "Extensions" tab instead. Not sure.

Incidentally, the "Find More add-ons" button takes you outside of Thunderbird to ATN in your browser in current Nightly, that definitely needs to be fixed.

Blocks: 1605360
You need to log in before you can comment on or make changes to this bug.