AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.094 Firefox os v1.0.1 Mozilla build ID:20130502070201 +++ This bug was initially created as a clone of Bug #429031 +++ DEFECT DESCRIPTION: No different icons to specify differnt types of attachment. Only one icon for all the attachment (a papr clip icon). REPRODUCING PROCEDURES: No different icons to specify differnt types of attachment. Only one icon for all the attachment (a papr clip icon). EXPECTED BEHAVIOUR: It will be good to have different icons to specify different type of attachment ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE:5/5 For FT PR, Please list reference mobile's behavior: ++++++++++ end of initial bug #429031 description ++++++++++
test not ok on AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.158 Firefox os v1.1 Mozilla build ID:20130709070206 and this PR should be fixed on V1.1
Sending this over for 1.2 consideration, and asking the product team to consider this request.
blocking-b2g: leo? → koi?
We would not block any release on this. Moving NI to UX for comment on the priority of this. If they are in agreement, it should be added to the backlog for email.
blocking-b2g: koi? → -
Flags: needinfo?(ffos-product) → needinfo?(firefoxos-ux-bugzilla)
Flagging Rob and Jacqueline on this, as they're on Productivity and may have some recommendations here.
Changing the flag for Rob to Eric, in case Eric is aware of any icon developments here, and leaving Jacqueline (so Rob can focus on other stuff he has to work on this week).
(In reply to Stephany Wilkes from comment #5) > Changing the flag for Rob to Eric, in case Eric is aware of any icon > developments here, and leaving Jacqueline (so Rob can focus on other stuff > he has to work on this week). to my knowledge there hasn't been developments for this, but Peter would know for sure. Peter are you aware of we are developing different icons for different types of email attachments?
mark koi? for 1.2
blocking-b2g: - → koi?
Summary: [Buri][TMO-48035][Email]No different icons for different type of attachment. → [Buri][Shira-48035][Email]No different icons for different type of attachment.
I don't know of any plans to support different icons for attachment types, and neither does Patryk.
triage: New feature request, will not block 1.2
blocking-b2g: koi? → -
is this going into your backlog? thanks
(In reply to Joe Cheng [:jcheng] from comment #10) > is this going into your backlog? thanks No, per comment #8 it looks like there are no plans for this feature at this time.
Hi,is it ok for v1.2 even not blocker?
(In reply to Jack Liu from comment #12) > Hi,is it ok for v1.2 even not blocker? No, we are not working on this for 1.2. I'm going to resolve as invalid since there are no plans for this feature at this time.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
Can we add this to backlog - as this is a request from Poland.
:WDM, is there a specific list of MIME types/families for which icons are desired? Or is it something more like it's presumed that if the device can handle the MIME type that there's a special-ish icon for it? The latter presumes some type of platform support for mapping web activities to the apps that advertise the ability to handle them, retrieving their icon, etc. The former is a lot easier but also could be misleading from a UX perspective; just because we can show a cool icon for an Excel document does not mean we could open it.
NI on Adam to work with UX to determine if this should be added to backlog. If we do decide to add this functionality, it seems low in priority relative to other email/calendar functionality.
Flags: needinfo?(ffos-product) → needinfo?(arogers)
no special icon that is requested - but the icon should be shown when we can handle the attachment - if we can not handle an attachment it should be a generic icon.
(In reply to Wilfred Mathanaraj [:WDM] from comment #17) > no special icon that is requested - but the icon should be shown when we can > handle the attachment - if we can not handle an attachment it should be a > generic icon. Hm, this is still a little ambiguous, mainly because my question was not clear enough. Here are the implementation options from the e-mail app's perspective: A) Show icons for all of the MIME types Firefox OS supports as shipped. No support for MIME types supported because of installed apps. B) Ship icons for all the popular MIME types out there in the world and: B1) Show the icons always, without knowing whether there is an activity that supports it. B2) Initially, only show the icons for types Firefox OS supports, but once we support letting the user download any MIME type, let the user try and open it. Once we open it via a web activity and don't get back an error, show the icon if we have it for all attachments of that type in the future (or until we get an error.) C) It's the download manager's problem. Have the download manager expose a Datastore that includes MIME types and icons. We just sync those and use those. If the download manager is fancy, it will let newly installed apps add new icons to the Datastore. D) It's a platform problem. Expose an explicit WebAPI that says what MIME types we support and provides the icons. I'm choosing to interpret what you said as option 'A' because it is the thing with the least effort, but I'm needinfo-ing you again so we can be sure while it's still fresh in your mind. I'm also reopening this bug for now since it's a reasonable extension to propose and if we're saying NO for ~forever, we should WONTFIX.
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Priority: P1 → --
Resolution: INVALID → ---
:arog created an explicit user story for this on bug 940368 choosing option 'A'. I think a reasonable plan for now is to dupe any requests to that bug or WONTFIX them since 'B' is unwieldy and 'C' and 'D' require platform support. Once we have platform support planned or implemented, we can have an enhancement bug.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 940368
You need to log in before you can comment on or make changes to this bug.