Closed Bug 1001861 Opened 8 years ago Closed 4 years ago

[Meta] Support short_name in web app manifests on FxOS

Categories

(Firefox OS Graveyard :: Gaia, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
2.2 S6 (20feb)

People

(Reporter: clouserw, Assigned: cserran)

References

Details

(Keywords: feature, uiwanted, Whiteboard: [dependency: marketplace-partners][systemsfe])

Original discussion on the mailing list [1].

This bug is to add support for an optional 'short_name' field in webapp manifests.  If that field exists and the device thinks it is appropriate to use (you are displaying the name in a space constrained area like an icon grid) you should use the short_name instead of the name.


[1] https://groups.google.com/forum/#!topic/mozilla.dev.webapps/Vzv3evC778Q
Note related bugs:

Bug 1001860 - Support short_name in web app manifests on desktop
Bug 1001861 - Support short_name in web app manifests on FxOS
Bug 1001862 - Support short_name in web app manifests on Android
Bug 1001864 - Show short_name in reviewer tools
As part of this change, it would be good to show _both_ names somewhere its possible to check for any funny business.  Most likely in the settings app maybe, under app permissions section?
Whiteboard: [dependency: marketplace]
We need a spec and a security review to decide where we should show the short name and where we should keep the full name. Suggest converting this to FxOS/Gaia::Homescreen bug if we only need the short name in home screen, or to a meta bug if we need to convert to short name to more places.

(Note that we show app name in cards view, notifications etc too not just homescreen & settings)
On the W3C side, this is a V2 feature. 
https://github.com/w3c/manifest/issues/23
Whiteboard: [dependency: marketplace] → [dependency: marketplace-partners]
Sandip, how can we nominate this as a b2g 2.2 feature?
Flags: needinfo?(skamat)
feature-b2g: --- → 2.2?
Flags: needinfo?(skamat)
We have a meta for supporting the W3C manifest spec.  I've linked this bug to that one.
Blocks: 1003890
See also: bug 1071583
See Also: → 1071583
Blocks: 1075704
No longer blocks: 1003890
Component: General → DOM: Apps
Product: Firefox OS → Core
Putting this bug in the Apps API component for any platform support that is needed when parsing manifests, we many need individual additional bugs in Gaia once we have a UX spec for the places where this property should be used.
Morphing this into homescreen bug as suggested by Alive. It looks like we may not need Gecko support for this in Firefox OS. Let's start by adding support to the homescreen and file follow-ups if we want to use short_name in other places.
Component: DOM: Apps → Gaia::Homescreen
Keywords: feature
Product: Core → Firefox OS
Does this still be introduced as a new feature for 2.2 or postponed?
Flags: needinfo?(bfrancis)
We are still working on Web Manifest for 2.2 but it is not a committed feature. We don't have a UX spec for where the short_name should be used though (adding uiwanted).

This feature could also be added independently of Web Manifest support for Open Web App manifests.

Francis, who owns the UX for homescreen?
Flags: needinfo?(bfrancis) → needinfo?(fdjabri)
Keywords: uiwanted
Candice, should it be system front end team's scope?
feature-b2g: 2.2? → ---
Flags: needinfo?(cserran)
this will be in 2.2. Updated whiteboard and feature flag
feature-b2g: --- → 2.2+
Flags: needinfo?(cserran)
Whiteboard: [dependency: marketplace-partners] → [dependency: marketplace-partners][systemsfe]
Assignee: nobody → bfrancis
Since I can't find the UX spec, I suppose it will only include Web Manifest support for Open Web App manifests, and no UI changes now. Please correct me if I am wrong.
I think we still need a UX spec to define where short_name should be used and where name should be used.
Adding actual apps to make this more clear with real-life use cases:

name / short_name:
- Yahoo Weather / Weather
- Where's My Water? / Water?
- This American Life /  This Am Life
- Hipmunk Travel - Hotels & Flights / Hipmunk

iOS similar functionality by allowing editing the long app name during store submission. The short name is shown on the homescreen and task switcher while the long name is only shown from within the app store.
(In reply to Harald Kirschner :digitarald from comment #16)
> iOS similar functionality by allowing editing the long app name during store
> submission. The short name is shown on the homescreen and task switcher
> while the long name is only shown from within the app store.

The long name is supposed to provide an alternative way to search for an app (as it does in iOS). A marketplace, or similar site, can use the long name, but its primary purpose is to facilitate searching for the application on the device.
I've specified in the Web manifest spec that the short name should be used in the add to homescreen dialog. 
I've also added similar notes to the task manager spec to state that the short name should be used in the task manager. 
Katie, please could you update the home screen spec to also say that the app labels should use the short name if possible.
Flags: needinfo?(fdjabri) → needinfo?(kcaldwell)
yes, will update home screen spec and let Chris know.
Flags: needinfo?(kcaldwell)
Ben, would you like me to file a separate bug for dealing with this on the homescreen grid, or will you just deal with all the cases in this bug?
Flags: needinfo?(bfrancis)
Hi Chris, I think we should have a separate bug for each usage as they're likely to be distributed across different apps! Thanks.
Flags: needinfo?(bfrancis)
Depends on: 1121466
Target Milestone: --- → 2.2 S6 (20feb)
Let's make this a meta bug and track the changes in individual apps.
Assignee: bfrancis → nobody
Component: Gaia::Homescreen → Gaia
Summary: Support short_name in web app manifests on FxOS → [Meta] Support short_name in web app manifests on FxOS
Depends on: 1124144
Depends on: 1124146
I am creating test cases and have some questions.
1. Will short_name be used in search app results?
2. Is there any correlation between "name" and "short_name"? Do we have any rule for it? Are we going to use "app-validator" or some methods to verify its correctness?
3. What is the maximum length of "short_name"? It seems not be defined in W3C spec.
Flags: needinfo?(bfrancis)
> Will short_name be used in search app results?

I personally hope so - but I'm not involved with that side of things. 

> 2. Is there any correlation between "name" and "short_name"? Do we have any rule for it? Are we going to use "app-validator" or some methods to verify its correctness?

Depends where each is shown. Short name is designed to be shown under the icon on the home screen. The longer name is designed to be shown in a search result context (search engine or to assist in local search) 

> 3. What is the maximum length of "short_name"? It seems not be defined in W3C spec.

This is by design :) Short name is about context of usage, not about its length. Generally, the short_name might be shorter than the name, but not necessarily always (for whatever reason).
> > 3. What is the maximum length of "short_name"? It seems not be defined in W3C spec.
> 
> This is by design :) Short name is about context of usage, not about its
> length. Generally, the short_name might be shorter than the name, but not
> necessarily always (for whatever reason).

It seems that in Firefox OS 2.x, the home screen icon label will display up to 10-12 characters depending on the character widths.  In Firefox OS 1.x, it is less.   So if that is the context, you may want to keep this in mind.
 In Firefox OS 1.x,
> it is less.   So if that is the context, you may want to keep this in mind.

Now that I think about it, short name is irrelevant for fxos 1.x.
> Will short_name be used in search app results?

Not currently, Francis should we file a bug for that?

I'm starting to wonder where we're actually going to use the full name...
Flags: needinfo?(bfrancis) → needinfo?(fdjabri)
We could also add short name as a search term for an app to the Marketplace.  


Full name should probably be used in the app permission setting to help distinguish apps that may use the same short name.
Depends on: 1131338
(In reply to Ben Francis [:benfrancis] from comment #27)
> > Will short_name be used in search app results?
> 
> Not currently, Francis should we file a bug for that?
> 
> I'm starting to wonder where we're actually going to use the full name...

Hi Ben, I've filed bug 1131338 and made it blocking for this bug.
Thanks Francis.

What about the Settings app? I suspect that as David says, in the context of app permissions we should probably display both names where available.
Depends on: 1134680
(In reply to Ben Francis [:benfrancis] from comment #30)
> Thanks Francis.
> 
> What about the Settings app? I suspect that as David says, in the context of
> app permissions we should probably display both names where available.

I'm not sure about this. I think using the short name should be good enough - hopefully the context will disambiguate which app is being referred to, so I would keep just the short name for a permission dialog, unless there's a security requirement to do otherwise. Any thoughts, Paul?
Flags: needinfo?(fdjabri) → needinfo?(ptheriault)
blocking-b2g: --- → 2.2+
feature-b2g: 2.2+ → ---
Need UX input here for settings app which is still outstanding. Post FL this needs TPE to confirm remaining work and if we should punt to next release.
Flags: needinfo?(ofeng)
Flags: needinfo?(hochang)
Flags: needinfo?(chuang)
@Jenny, need your comment on Settings part. :)
Flags: needinfo?(ofeng) → needinfo?(jelee)
@Helen, need your help on Settings. thanks!
Flags: needinfo?(chuang) → needinfo?(hhuang)
Hi all,

Please see my reply in Bug 1134680 comment 6. Thanks!
Flags: needinfo?(jelee)
Depends on: 1137501
Settings app work is done in bug 1134680 but needs uplift to 2.2.
Flags: needinfo?(hochang)
(In reply to Francis Djabri [:djabber] from comment #31)
> (In reply to Ben Francis [:benfrancis] from comment #30)
> > Thanks Francis.
> > 
> > What about the Settings app? I suspect that as David says, in the context of
> > app permissions we should probably display both names where available.
> 
> I'm not sure about this. I think using the short name should be good enough
> - hopefully the context will disambiguate which app is being referred to, so
> I would keep just the short name for a permission dialog, unless there's a
> security requirement to do otherwise. Any thoughts, Paul?

From a security perspective I suggest the following:
1. Be as consistent as possible - i.e. if only showing one name (short_name) then use that one name for install, homescreen, prompts and settings. 
2. Any restrictions we have on names, we must also apply to short_name (otherwise short_name becomes away to bypass this restriction)

As such there are two bugs suggested here:
- 1137501: to show the short_name on install, so that the user knows to associate the short_name with the app, rather than the regular name which won't be shown after install (iiuc)
- 1137498: to extend name validation checks to cover the short_name as well when doing app updates

That's all the cases i can think of. But is there anywhere else in the OS that we might show the full name, and we should perhaps show the short_name? Task manager? Notification Tray? Maybe these are all already changed but I'm not 100% on all of the places we show the full name.
Flags: needinfo?(ptheriault)
Using short names in Setting is okay for me, seems it won't cause any visual changes. Mainly I will follow the UX's decision.
Flags: needinfo?(hhuang)
If the value of short_name is an array or an object, are we going to use "name" instead of "short_name" and then raise a warning mentioned in W3C spec [1]?

Currently, its behavior is like:
* Array - "short_name": ["Json", "Array", "Test"], app name on Homescreen: "Json,Array,Test"
* Object - "short_name": {"Jason":"true", "Object":"true"}, app name on Homescreen: "[object object]"

Besides, maybe WebIDE can perform basic checking for short_name if possible.

[1] https://w3c.github.io/manifest/#dfn-steps-for-processing-the-short_name-member
Put Candice as the assignee of this meta
Assignee: nobody → cserran
I am very interested to know why this is marked as blocking-b2g: 2.2+ 

Can we document the decision-making process when the flag is flipped?
This should have been feature blocking, not blocking-b2g. Changed. waiting on reviews from tpe on the dependencies here. Will need uplift approval when done
blocking-b2g: 2.2+ → ---
feature-b2g: --- → 2.2+
Depends on: 1139735
Depends on: 1140060
removing feature tag as we have tagged the dependent bugs and new bugs will be filed for backlog
feature-b2g: 2.2+ → ---
Depends on: 1142572
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.