Closed
Bug 1001861
Opened 11 years ago
Closed 7 years ago
[Meta] Support short_name in web app manifests on FxOS
Categories
(Firefox OS Graveyard :: Gaia, defect)
Firefox OS Graveyard
Gaia
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
Reporter | ||
Comment 1•11 years ago
|
||
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
Comment 2•11 years ago
|
||
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?
Updated•10 years ago
|
Whiteboard: [dependency: marketplace]
Comment 3•10 years ago
|
||
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)
Comment 4•10 years ago
|
||
On the W3C side, this is a V2 feature. https://github.com/w3c/manifest/issues/23
Updated•10 years ago
|
Whiteboard: [dependency: marketplace] → [dependency: marketplace-partners]
Comment 5•10 years ago
|
||
Sandip, how can we nominate this as a b2g 2.2 feature?
Flags: needinfo?(skamat)
Updated•10 years ago
|
feature-b2g: --- → 2.2?
Flags: needinfo?(skamat)
Comment 6•10 years ago
|
||
We have a meta for supporting the W3C manifest spec. I've linked this bug to that one.
Blocks: 1003890
Updated•10 years ago
|
Updated•10 years ago
|
Component: General → DOM: Apps
Product: Firefox OS → Core
Comment 8•10 years ago
|
||
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.
Comment 9•10 years ago
|
||
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.
Comment 10•10 years ago
|
||
Does this still be introduced as a new feature for 2.2 or postponed?
Flags: needinfo?(bfrancis)
Comment 11•10 years ago
|
||
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
Comment 12•10 years ago
|
||
Candice, should it be system front end team's scope?
feature-b2g: 2.2? → ---
Flags: needinfo?(cserran)
Assignee | ||
Comment 13•10 years ago
|
||
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]
Updated•10 years ago
|
Assignee: nobody → bfrancis
Comment 14•10 years ago
|
||
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.
Comment 15•10 years ago
|
||
I think we still need a UX spec to define where short_name should be used and where name should be used.
Comment 16•10 years ago
|
||
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.
Comment 17•10 years ago
|
||
(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.
Comment 18•10 years ago
|
||
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)
Comment 19•10 years ago
|
||
yes, will update home screen spec and let Chris know.
Flags: needinfo?(kcaldwell)
Comment 20•10 years ago
|
||
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)
Comment 21•10 years ago
|
||
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)
Assignee | ||
Updated•10 years ago
|
Target Milestone: --- → 2.2 S6 (20feb)
Comment 22•10 years ago
|
||
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
Comment 23•10 years ago
|
||
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)
Comment 24•10 years ago
|
||
> 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).
Comment 25•10 years ago
|
||
> > 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.
Comment 26•10 years ago
|
||
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.
Comment 27•10 years ago
|
||
> 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)
Comment 28•10 years ago
|
||
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.
Comment 29•10 years ago
|
||
(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.
Comment 30•10 years ago
|
||
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.
Comment 31•10 years ago
|
||
(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)
Assignee | ||
Updated•10 years ago
|
blocking-b2g: --- → 2.2+
feature-b2g: 2.2+ → ---
Assignee | ||
Comment 32•10 years ago
|
||
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)
Comment 33•10 years ago
|
||
@Jenny, need your comment on Settings part. :)
Flags: needinfo?(ofeng) → needinfo?(jelee)
Comment 34•10 years ago
|
||
@Helen, need your help on Settings. thanks!
Flags: needinfo?(chuang) → needinfo?(hhuang)
Comment 35•10 years ago
|
||
Hi all, Please see my reply in Bug 1134680 comment 6. Thanks!
Flags: needinfo?(jelee)
Updated•10 years ago
|
Comment 36•10 years ago
|
||
Settings app work is done in bug 1134680 but needs uplift to 2.2.
Flags: needinfo?(hochang)
Comment 37•10 years ago
|
||
(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)
Comment 38•10 years ago
|
||
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)
Comment 39•10 years ago
|
||
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
Comment 40•10 years ago
|
||
Test cases in Moztrap https://moztrap.mozilla.org/manage/cases/?&pagenumber=1&pagesize=20&sortfield=case__priority&sortdirection=asc&filter-tag=3295&filter-productversion=217&filter-suite=869
Flags: in-moztrap+
Comment 42•10 years ago
|
||
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?
Assignee | ||
Comment 43•10 years ago
|
||
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+
Assignee | ||
Comment 44•10 years ago
|
||
removing feature tag as we have tagged the dependent bugs and new bugs will be filed for backlog
feature-b2g: 2.2+ → ---
Comment 45•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Updated•7 years ago
|
Keywords: dev-doc-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•