497052 - 2 old nameless experimental themes need to be disabled

Status: RESOLVED WONTFIX

(addons.mozilla.org Graveyard :: Administration, defect, P3)

Description

[Dave Garrett]

Apparently there's 2 nameless experimental themes. Noticed it because preview sorts them to the beginning on the sort by name view now. However, they are on production too. Have been for a while; it looks like they're quite old. Please disable them on production and preview.

https://addons.mozilla.org/en-US/firefox/addon/4761
https://addons.mozilla.org/en-US/firefox/addon/6573

This shouldn't be possible anymore with the new developer console, right?

Comment 1

[Dave Garrett]

Correction, they're showing with the all the same problems on both production and preview. Guess they were just never noticed before.
https://addons.mozilla.org/en-US/firefox/browse/type:2/cat:all?show=20&exp=on&sort=name
https://preview.addons.mozilla.org/en-US/firefox/browse/type:2/cat:all?show=20&exp=on&sort=name

Comment 2

[fcp]

The problem is not only with themes but with all kinds of add-ons.
https://addons.mozilla.org/en-US/firefox/browse/type:1/cat:all?show=20&exp=on&sort=name
Note that some of the “nameless” add-ons have names in locales other than English.  This suggests that the authors do not intend to leave the name as empty.

The real problem is that the authors are allowed to set the name of their add-ons to the empty string.  I thought that leaving the name field empty meant “use the default value,” especially because adding a new locale in the developer tool created an empty name field.  It took one day or two for me to realize that I was wrong.  I do not find the user interface of the “Edit Add-on Descriptions” form very intuitive.

Comment 3

[Dave Garrett]

+1
https://addons.mozilla.org/en-US/firefox/addon/13056

Not falling back to default locale correctly? This one shows fine in zh-TW:
https://addons.mozilla.org/zh-TW/firefox/addon/13056

Same sort of thing as bug 497276?

However, I mass tested the older two and they have no name in any locale. (new bug?)

Comment 4

[Fred Wenzel [:wenzel]]

(In reply to comment #3)
> +1
> https://addons.mozilla.org/en-US/firefox/addon/13056

Thanks. It fell back to its default en-US locale correctly, but that one was empty. I copied its name from Taiwanese to en-US manually. Being able to store empty names in the first place is indeed a new bug.

Comment 5

[Fred Wenzel [:wenzel]]

(In reply to comment #0)
> it looks like they're quite old. Please
> disable them on production and preview.

I concur. Rey, it is your call if the authors need to be notified or if we treat these as abandoned (considering they do not support anything beyond Fx 2.0)

Comment 6

[Dave Garrett]

(In reply to comment #4)
> Being able to store
> empty names in the first place is indeed a new bug.

Just tested this on preview. It let me just change Flagfox's name to one empty en-US string. Doesn't seem to have any requirements at all. :) Filed bug 510046.

Comment 7

[fcp]

As I wrote in comment 2, there are many nameless add-ons other than themes, and I do not see any reason why you should treat nameless themes differently from nameless add-ons of other types.  I suggest Wontfix.

Comment 8

[Rey Bango]

(In reply to comment #5)
> (In reply to comment #0)
> > it looks like they're quite old. Please
> > disable them on production and preview.
> 
> I concur. Rey, it is your call if the authors need to be notified or if we
> treat these as abandoned (considering they do not support anything beyond Fx
> 2.0)

Hey Fred. I think we need to contact the authors and ask them to update this so that they don't show up as empty. I'll do that.

In addition, I agree with you that we shouldn't be allowing blank names & this should be looked at.

Comment 9

[Dave Garrett]

(In reply to comment #7)
> As I wrote in comment 2, there are many nameless add-ons other than themes, and
> I do not see any reason why you should treat nameless themes differently from
> nameless add-ons of other types.  I suggest Wontfix.

They all need to be dealt with. For ones that are old FF2 add-ons, there's no real need to keep them around.

(In reply to comment #2)
> Note that some of the “nameless” add-ons have names in locales other than
> English.

These just need to be fixed. The 2 themes here have nothing at all. (yeah, there's probably extensions like this too)

Is there some SQL we could run to delete all empty locales for add-ons with at least one locale with a name?

Comment 10

[Rey Bango]

So in re-reading the entire bug, I missed the long list provided by fcp. Because this is more than just 2 themes, I'd like to see if WebDev could provide a solution for this. Let me chat with the team to see what the best solution would be before I go off contacting quite a number of authors.

Comment 11

[fcp]

(In reply to comment #9)
> These just need to be fixed. The 2 themes here have nothing at all. (yeah,
> there's probably extensions like this too)

If nameless add-ons other than themes are dealt with as well, I have no objection.  But maybe the “Don't allow blank add-on names” part of bug 510046 should be fixed first to avoid repetition (if it is not too hard).

(In reply to comment #10)
> So in re-reading the entire bug, I missed the long list provided by fcp.
> Because this is more than just 2 themes, I'd like to see if WebDev could
> provide a solution for this. Let me chat with the team to see what the best
> solution would be before I go off contacting quite a number of authors.

Note that the ~40 add-ons on top of the list in comment 2 are those which are nameless *in en-US*.  Some of them have a name in some locales.

We might want to treat the add-ons which are nameless in all locales (such as the 2 old themes found by Dave, according to comment 3) differently from the add-ons which are nameless in only some of the locales.  If we do something about add-ons of the latter kind, note that there are probably some add-ons which have a name in en-US but are nameless in locales other than en-US.

Comment 12

[Jorge Villalobos [:jorgev] (he/him)]

I don't see any blank add-ons on comment 2 other than the initial 2. I have disabled those, given that they're clearly abandoned and irrelevant at this point.
Marking this as fixed.

Comment 13

[fcp]

(In reply to comment #12)
> I don't see any blank add-ons on comment 2 other than the initial 2. I have
> disabled those, given that they're clearly abandoned and irrelevant at this
> point.
> Marking this as fixed.

I do not know why you and I see different lists, but in my environment the first 64 extensions on the list in comment 2 are all nameless and experimental.

Comment 14

[Jorge Villalobos [:jorgev] (he/him)]

You're right. I meant comment 1. I can still see a number of empty-named add-ons on the link in comment 2.
-> me

Comment 15

[Jorge Villalobos [:jorgev] (he/him)]

The search results no longer show empty add-on names. We check for this in the nomination process, so at least new public add-ons should have an adequate default name. Bug 510046 deals with restricting this at the application level, so I don't think there's any reason to keep this bug open.
Since we won't disable add-ons just because of their name, I'm resolving this as WONTFIX.