App Names for Applications in Marketplace Should Be Derived from the App Manifest

RESOLVED FIXED

Status

Marketplace
Consumer Pages
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Tyler, Assigned: dbialer)

Tracking

({dev-doc-needed, helpwanted})

dev-doc-needed, helpwanted
Points:
---

Firefox Tracking Flags

(blocking-kilimanjaro:-)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
When Find IP Address is installed on Windows, it installs properly. We've received feedback, and upon testing, it appears the app does not actually install on Mac though (but marketplace will still show it as installed).
Flagging qawanted - need to investigate the root cause of this issue.
Keywords: qawanted

Updated

6 years ago
Component: General → Web Apps
Product: Marketplace → Firefox
QA Contact: general → webapps
Version: 1.0 → 15 Branch
Looking at the manifest, only thing I see different than typical use is that everything is flushed left:

{
"version": "1.0",
"name": "IP Address",
"description": "Find your IP Address instantly!",
"developer": {
"name": "Find Your IP Fast LLC",
"url": "http://get.youripfast.com"
},
"installs_allowed_from": [
"https://marketplace.mozilla.org"
],
"default_locale": "en"
}
Created attachment 622759 [details]
IP Address on Mac

What does "not actually install" mean? It was installed as "IP Address" in my Applications directory. The name on the Marketplace is "Find IP Address" but it's called "IP Address" in the manifest. And the name in the manifest is what it is natively installed as.

Comment 4

6 years ago
You are right. The truth is that is confusing. Maybe we should enforce the name to be the same as the one it's listed with?
(In reply to Ibai from comment #4)
> You are right. The truth is that is confusing. Maybe we should enforce the
> name to be the same as the one it's listed with?

Hmm, I don't think we can do that on the desktop side. We follow the application name specified in the manifest. This sounds like a marketplace problem with allowing the application name to be different than the application manifest.

Updated

6 years ago
Keywords: qawanted

Updated

6 years ago
Component: Web Apps → Consumer Pages
Product: Firefox → Marketplace
QA Contact: webapps → consumer-pages
Version: 15 Branch → 1.0

Updated

6 years ago
Summary: Find IP Does not install properly on Mac → App Names for Applications in Marketplace Should Be Derived from the App Manifest
Wil and Krupa - This sounds problematic if marketplace allows this. Can you confirm that this is a marketplace problem?
During submission we extract the name specified in the manifest. The developer is then able to change the name to whatever he/she wants. This is expected behaviour, and this happens on all other app stores.

We can flat out reject apps whose manifest names don't match their names in the Marketplace but that seems kind of lame.

Comment 8

6 years ago
(In reply to Jason Smith [:jsmith] from comment #6)
> Wil and Krupa - This sounds problematic if marketplace allows this. Can you
> confirm that this is a marketplace problem?

I don't think this is a problem at all. We want the app name to be unique. If an app exists with the name specified in the manifest, we should allow the user to edit it and continue with the upload. 

Think of the scenario when the developer wants to change the appname for whatever reason. How do we allow that?

Comment 9

6 years ago
We should however talk about propagating that change so that the app name is used on the desktop side after install.
(In reply to krupa raj 82[:krupa] from comment #9)
> We should however talk about propagating that change so that the app name is
> used on the desktop side after install.

As I said above, the app manifest name is the final decision maker, not the marketplace app name. If the app developer wants to change the name of the app, they need to change the app manifest as well. Maybe the right resolution here is that if the app developer wants to change the name of the app, then they need to change the name in the app manifest as well before allowing the app to be installed again. Otherwise, we'll have a problem such as the following:

Marketplace names the app as "Find IP Address", app is named as "IP address" in manifest. Installing the app can occur from anywhere that the app developer chooses - not just marketplace. If we allowed override on marketplace, then we end up in an inconsistency where the name of the app on marketplace is different when installed from anywhere else the app is installed (take for instance, if the app developer hosts a link to install the app directly from their site).

Here's what I suggest - We need to do syncing between the app manifest and marketplace name (error checking, syncing, etc).
Myk and Anant - Thoughts? There's disagreement if this is a marketplace or desktop bug.
I agree with Jason's analysis - I think we shouldn't be asking developers to re-enter any information that is already in the manifest, including the name. If a manifest they upload conflicts with another app that's already on the marketplace, we could inform them and ask them to reupload a manifest with the changed name.

Out of curiosity, why do we require app names to be unique on the Marketplace?
(In reply to Anant Narayanan [:anant] from comment #12)
> Out of curiosity, why do we require app names to be unique on the
> Marketplace?

This allows partners and people to reserve their app names early. What if there were ten apps named "Twitter"?
Nominating for k9o, as this is an integration bug between marketplace and the web runtime that affects the primary user story for going to marketplace and installing an application.
blocking-kilimanjaro: --- → ?
(In reply to Chris Van Wiemeersch [:cvan] from comment #13)
> (In reply to Anant Narayanan [:anant] from comment #12)
> > Out of curiosity, why do we require app names to be unique on the
> > Marketplace?
> 
> This allows partners and people to reserve their app names early. What if
> there were ten apps named "Twitter"?

That's a pretty good reason. We should tread carefully, as requiring developers to change the app name in the manifest just because it wasn't available at the Mozilla Marketplace isn't going to scale well. This will mean the developer has to pick a name that is available on *all* the app stores he is planning to submit to (now and in the future) and put that in the manifest, which isn't a great experience.
Even if we did require developers to change their app's name in the manifest, and then we derived the app's name in the marketplace from its name in the manifest, and then we didn't let developers change that name in the marketplace, that wouldn't completely resolve the problem, since developers could change the name in the manifest after the store approves the app.  But perhaps it would still be an improvement.

Alternately, can the store provide the browser with the name by which it knows the app, so the browser can install it with that name?
(In reply to Myk Melez [:myk] [@mykmelez] from comment #16)
> Alternately, can the store provide the browser with the name by which it
> knows the app, so the browser can install it with that name?

I believe right now installation calls start at navigator.mozapps.install, which takes in the manifest URL. That's correct behavior per the spec. I'd rather not fight a spec change and instead change the caller's behavior to handle this better.

https://developer.mozilla.org/en/Apps/Apps_JavaScript_API/navigator.mozApps.install

Updated

6 years ago
OS: Mac OS X → All
Hardware: x86_64 → All
blocking-kilimanjaro: ? → -
Until we get a fix for this, we should make sure developers know to keep these names in sync themselves.
Keywords: dev-doc-needed, helpwanted
(In reply to Myk Melez [:myk] [@mykmelez] from comment #16)
> Alternately, can the store provide the browser with the name by which it
> knows the app, so the browser can install it with that name?

I very much support this approach. Letting the apps provide a different name through the manifest from what is in the listing leads to all sort of bad scenarios IMO.

I believe the name collision is a non-issue, as it already exists among other marketplaces and I haven't heard significant debates about it.
What is the next steps for this bug?  It sounds like the spec and browser needs to change to accept a name from the marketplace and then the marketplace needs to send it?
(In reply to Wil Clouser [:clouserw] from comment #20)
> What is the next steps for this bug?  It sounds like the spec and browser
> needs to change to accept a name from the marketplace and then the
> marketplace needs to send it?

That seems awfully confusing. In my opinion, for hosted apps, we should *not* allow the name to be changed from the Developer Hub. The manifest remains the source of truth for name and icons, and we pull it in regularly to make sure it's up to date.
assigning to product
Assignee: nobody → dbialer

Comment 23

6 years ago
Bear in mind that this issue is further compounded by locales: If a user is browsing Marketplace in English but their device has a locale set to, say, Portugese, the app name on the device will likely not match the app name of the installed app (even though they are indeed both pulling from the manifest).

This problem is even further compounded by apps which provide locales which are not supported on Marketplace. A developer may provide a localized translation of their app name for, say, "foo-BAR". On Marketplace, the app cannot expose the "foo-BAR" name, though a device which is set to use "foo-BAR" may [unexpectedly] display that localized name (which the user has never seen before). This will be especially confusing if the app name contains non-Latin characters.

These two scenarios fall into the same bucket as above, but cannot be resolved from the Marketplace side without some kind of change on the client side.
(Assignee)

Comment 24

6 years ago
I agree with Chris in that the "source of truth" for the app name should be the manifest and we should not allow it to be changed unless the manifest is changed.

The manifest, to my understanding, can have a different set name for each locale - which I would think would be the proper way to set a localized name.  We should be pulling the names for each locale from the marketplace, and as with the default name, have these localized names displayed for each region.

In the case of unsupported regions, it should use the default name.

So, Marketplace should check the manifest for names by locale and store these, and use these for the name of the App in the listing.  It should not allow updates unless the manifest is updated.

I agree with Felipe in that I don't see any problem with names being non-unique.
(Assignee)

Comment 25

6 years ago
Created attachment 680748 [details]
Shows edit screen where name should be pulled into listing

Added this as an illustration of where name should be pulled (in localization information editing).

Comment 26

6 years ago
(In reply to David Bialer [:dbialer] from comment #24)
> The manifest, to my understanding, can have a different set name for each
> locale - which I would think would be the proper way to set a localized
> name.  We should be pulling the names for each locale from the marketplace,
> and as with the default name, have these localized names displayed for each
> region.
> 
> In the case of unsupported regions, it should use the default name.

This doesn't consider apps that have unsupported "default" locale. It also doesn't consider if the developer changes the app's default locale or if all of the supported locales are removed from the manifest.

If a developer provides a description for an app on the en-US version of the listing, but then removes the en-US locale from his manifest, do we delete his en-US description?

It seems a bit convoluted to have the localization of the app tied so closely to the manifest when the majority of the fields for the listing (i.e.: everything except the name) are not pulled from the manifest. We cannot pull required fields (i.e.: privacy policy, support email) from the manifest, so this requires developer interaction, which we don't have if the information is being pulled automagically.

> So, Marketplace should check the manifest for names by locale and store
> these, and use these for the name of the App in the listing.  It should not
> allow updates unless the manifest is updated.

Does this also mean that apps will need to be flagged for re-review when they change their name in the manifest?
(In reply to David Bialer [:dbialer] from comment #24)
> I agree with Felipe in that I don't see any problem with names being
> non-unique.

Two apps named "Twitter" - isn't that something we want to avoid?

Comment 28

6 years ago
As I understand it, only TM owners can use a TM and they should be able to use it properly. I assume that reviews will enforce it.

That said, I see apps called "Soccer", "Baseball", etc... If we enforce uniqueness...we will have a battle for the "first come first served" names. Giving the ability to have multiple apps with the same name will discourage the super common names.
(Assignee)

Comment 29

6 years ago
I don't see a problem with 2 or more apps named Twitter, though Twitter might and ask for a takedown of the other app if it violates a trademark.  We should not accept obvious trademark violations or impersonations (and we can take down).  The TM issue is of more concern.

So 10 apps with the same name, which is likely to happen with common names as Ibai suggests, can be further identified by the developer.   The first come first serve name usage encourages name squatting, even if an app is never approved.
(Assignee)

Comment 30

6 years ago
Regarding Matt's isues:

I think the major issue is that we are using language and locale in 3 different contexts:
1. in the manifest to indicate language of the app.
2. in the marketplace listing to give a description in a language, but not necessarily a reflection of the language of the app.
3. in the pricing to indicate region offered - which is used to pull listings matching a region, and presumably a language used in that region.

So what I propose is that we should try to align these as closely as possible, though there is no ideal way of doing this.  It is more a matter of setting a policy into how these are used, and communicating this to developers.

So the policy would be the manifest as the source of truth of names and regions supported by an app.

This wold mean that the name should be derived from the manifest and not editable in the listing.  If there is a name overide in locale information we should use that to populate the name for the language or region.  If a locale is in a manifest but there is no name overide, we should use the default name. This implies that if a developer wishes to have the app name translated for different languages, it should come from the manifest as well.  

Uploading a new manifest would be the method to change/add/delete app names in different languages - both to the app and to the listing.

The app name listed in the locale should be used for the app listing in a region.  If this doesn't exist then the default should be used.

If the default locale isn't a supported region and there isn't locale or overide name, then the app would only show up in "World" (rest of world) and in the language of the default locale.  If a default locale isn't set in the manifest, then I would think we should set to English (for any region).

This has its failings, to be sure.  For instance, in Germany, unless an app in English explicitly lists the locale for Germany (de) in the manifest, it would not be listed in Germany (assuming a Germany store only pulls german apps - which would be up to the regional store).

I don't believe a name change or addition/deletion/modifications of names should trigger a re-review.  I don't think this covers all corner cases and could lend itself to abuse, but I don't suggest we worry about this unless it becomes a problem.

We would use locale information to control the localized descriptions available.  If a locale is removed, the description is deactivated (if that is possible) though could be saved.

To summarize - we use the manifest as the source of truth.  

Does this make sense.

Comment 31

6 years ago
(In reply to David Bialer [:dbialer] from comment #30)
> If the default locale isn't a supported region and there isn't locale or
> overide name, then the app would only show up in "World" (rest of world) and
> in the language of the default locale.  If a default locale isn't set in the
> manifest, then I would think we should set to English (for any region).

We currently can't store translated data in Zamboni for locales that are not supported. I.e.: If the developer submits a manifest with the default locale xyz-ABC and there are no other supported locales, we can't store a translation in our database with the "xyz-ABC" locale because we have no way of getting that data back.

In this case, if we're using the manifest as the "source of truth", we'd be forced to reject the app. We couldn't store a listing for it.


> If a default locale isn't set in the
> manifest, then I would think we should set to English (for any region).

Every manifest must have a default locale, so that shouldn't be a problem.


> This has its failings, to be sure.  For instance, in Germany, unless an app
> in English explicitly lists the locale for Germany (de) in the manifest, it
> would not be listed in Germany (assuming a Germany store only pulls german
> apps - which would be up to the regional store).

We've already dealt with this problem: region and locale are not conflated. Region is defined here in the Edit Listing page:

http://cl.ly/image/472e3b103K3H

The developer has control over which regions the app is displayed for. The locale is used to display a translated name for the app in the language that the Marketplace visitor speaks. So an app could have an en-US and a de-DE locale and english-speaking persons in Germany would see an english listing and german-speaking persons in Germany would see the german translation.

Apps cannot have different translations for the same locale in different regions. Locales are universal, regions simply define which parts of the world an app can be viewed in.

TL;DR: Region is not defined in/by the manifest.


> We would use locale information to control the localized descriptions
> available.  If a locale is removed, the description is deactivated (if that
> is possible) though could be saved.

The problem here is this: we don't (and maybe can't) hide apps where there's no translation available in the visitor's locale. So if we have an en-US listing for the app and a pt-BR translation for the app and the developer removes the en-US version of the app name from the manifest (even though the app name *is the same in Portuguese as it is in English*), we'd be disabling the english listing and showing english-speaking users a Portuguese description for the app, even though the description isn't part of the manifest.

So here's the scenario: The developer has the following manifest:

{
"name": "Good App",
"default_locale": "pt-br",
"locales": {
    "en-us": {"name": "Good App"}
},
...
}

In order to have a listing in english (even if the app is fully translated internally), the app MUST include that duplicate name entry in the locales field. If the developer removes the en-us locale, we'd be disabling and removing the english translation of the app. All english-speaking visitors would start seeing the Portuguese version of the app's listing.

This is an incredibly unexpected behavior and is even worse than the current situation.

Our documentation would need to be updated to say, "If you want to have an english listing of your app on the Marketplace, you need to have a locale entry in `locales` that contains the app name, regardless of whether or not the app name is different for that locale". So if your app's name is "Twitter" in English and "Twitter in Portuguese, you'd still need to have that listed twice, just because we'd delete your Portuguese translation if you don't have the name "Twitter" listed as the Portuguese translation of the name.


Here's my suggested behavior:

1. The app name is not tied to any listing's translation (i.e.: removing or changing the app name in the manifest does not remove or change any other part of the listing).
2. The app name is not editable.
3. The default app name for every locale is the app name for "default_locale" in the manifest.
4. If available, a listing uses the app name defined for that locale in the manifest.

This would require the least amount of work on our end and would involve the fewest number of surprises for the developer.
(Assignee)

Comment 32

6 years ago
Sounds good.
From comment 31:
> 2. The app name is not editable.

This was added in the following commits:
https://github.com/mozilla/zamboni/commit/fbdba00 
https://github.com/mozilla/zamboni/commit/654ece7

(One removed editing of name from the submit flow, one removed editing of name from devhub.)

bug 828738 will allow name edits for packaged apps via new version upload.
bug 828737 will track manifest name changes for hosted apps.

All the locale stuff mentioned above hasn't been dealt with yet.
What's left here?
I think what's left is everything except #2 from comment 31...

1. The app name is not tied to any listing's translation (i.e.: removing or changing the app name in the manifest does not remove or change any other part of the listing).
3. The default app name for every locale is the app name for "default_locale" in the manifest.
4. If available, a listing uses the app name defined for that locale in the manifest.

Although, I'm not clear on the full details of these changes yet.
We don't allow name edits anymore. This is fixed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.