We need to display a placeholder for unknown file types and also create a menu to ask if they want to save it. Also on topic here is a "corrupt image" - do we want to use a placeholder for an image that can't load? I can't find the wireframes or visual design assets for this workflow, Ayman/Victoria can you help out here?

Blocking+. We have to ensure that these don't break stuff, at the very least.

(In reply to Corey Frang [:gnarf] [:gnarf37] from comment #0) > We need to display a placeholder for unknown file types and also create a > menu to ask if they want to save it. Yep, I think we will need a placeholder for unknown filetypes with a message bubble. Will talk to Victoria about this tomorrow - we can probable handle it straight into Visual Design > > Also on topic here is a "corrupt image" - do we want to use a placeholder > for an image that can't load? Corrupt files are handled in the metta pattern document.. however are you meaning that if the user selects an image in the message thread and that image fails to open because its corrupt that we should change the presentation of that image in the thread to indicate that it is corrupt and therefore encourage the user not to keep on selecting it (and therefore getting the 'this is corrupt' message again and again). If so that makes sense to me, and again is something i will discuss with Victoria tomorrow... let me know if i have misunderstood this ASAP please so i do not start the wrong conversations tomorrow. > > I can't find the wireframes or visual design assets for this workflow, > Ayman/Victoria can you help out here?

You understood me perfectly Ayman, thanks!

Hey Corey For 'unknown file type' we will need both an image that indicates that the fail cannot be opened and some text that explains this. For localization purposes the text needs to be outside of the image. I would put it underneath. I would use the sting 'file type not supported yet'. I think this gives the impression that the system is in evolution and unsupported file types will be supported in time. All UX beyond clicking the 'unknown file type' image are handled in document 'meta-pattern-previews' which is owned by Rob MacDonald. I will attach the file here for your reference.

reference comment 4

Hi Corey, I am working on this, since there are some other cases to cover, I am listing them and can you point if there is something missing in the list? Thumbnails for files where there's no preview: Music files Video files Photo files Other files (generic file icon over grey background to represent other not media files) Thumbnails with preview: Photo files Photo files with added frame for edge cases like photo booth strips and panoramic photos. Eventually we'll have video preview, but right now that's not techinically possible. Icons: Icon to indicate a file cannot be opened (This icon will be placed over the thumbnail, as an indicator) Icon to indicate a file is corrupt (This icon will be placed over the thumbnail, as an indicator) Is that correct? Can you tell me if there's the case whereby a file would not be supported but will have a preview anyways? Thanks!

Hard to tell if a file is "openable" before we try to open it. If there isn't an app to open, we will be adding this menu to save the file as per the meta patterns. I think you have all the cases listed here Victoria

Just updating the needinfo here - still need to get some files from victoria before I can work on this.

Sorry Corey, I am waiting for some material from Peter and Patryk. They'll provide the final icons for this. Pinging them.

Hi, sorry for the delay. Please refer to this bug to get all the image assets as well as specs: https://bugzilla.mozilla.org/show_bug.cgi?id=878042

Unassigning myself as I'm out this week and won't get to it - If it's still open when I get back, I'll focus on it then.

Taking, as it seems to be a natural follow-up of bug 878042.

https://github.com/mozilla-b2g/gaia/pull/10351 Most of the work had already been done for bug 878042. Now I just have to find a way to receive an MMS with an “unknown” attachment — i.e. an attachment that is not an image/audio/video file.

FTR, this is how a broken image attachment is rendered with this patch. The visual asset has been specified in bug 878042.

I’ve just updated the pull request on github, and opted to display the “corrupted” indicator /over/ the default placeholder, so it can be applied to audio/video attachment as well.

Comment on attachment 762163 [details] screenshot — broken image attachment (new) comments on the PR

Comments addressed.

Comment on attachment 761728 [details] link to pull request r=me with the latest changes that were asked for please add a test with a working blob and land only if tests are passing. If unsure you can still request another review from me or someone else :)

Test cases added, merged on master: https://github.com/mozilla-b2g/gaia/commit/3a7fe9ad5bcd19b0bfe582f507478802133cc77b FTR, I tried to use the .notInclude() assertion but it requires a very recent version of chai.js (≥1.6)… and it was not working as expected anyway. I’ll keep that in mind for the next major update of chai.js.

I was not able to uplift this bug to v1-train. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1-train git cherry-pick -x -m1 3a7fe9ad5bcd19b0bfe582f507478802133cc77b <RESOLVE MERGE CONFLICTS> git commit

Looks like it was already uplifted after all v1-train: 097e03232bcfc74db434d74413d774c6a04671f1 NI john ford for the hd uplift.

1.1hd: 097e03232bcfc74db434d74413d774c6a04671f1