AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.107 Firefox os v1.0.1 Mozilla build ID:20130514070202 +++ This bug was initially created as a clone of Bug #419943 +++ DEFECT DESCRIPTION: Can not display the expanded-name of attachment that has a long name REPRODUCING PROCEDURES: 1.Receive a mail with attachment that has a long name; 2.Check the attachment name,its expanded-name can not be displayed-->ko EXPECTED BEHAVIOUR: Please refer to the android phone behavior. 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 #419943 description ++++++++++ CONTACT INFO (Name,Phone number): DEFECT DESCRIPTION: REPRODUCING PROCEDURES: EXPECTED BEHAVIOUR: ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:
Clone from brother
Still same problem on V1.1, AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.171 Firefox os v1.1 Mozilla build ID:20130722070207 As it is not blocking, but I still think it is important, add Koi?
UX team; we need/want a strategy for how to deal with the super-long file-name. Our current idiom would be to trigger animated marquee scrolling of the name back-and-forth, but there are the alternate possibilities of causing the attachment list to grow in size and having tapping on the name display some type of pop-up where we have room to wrap. The argument against the marquee is that it can take a long time. The argument against the multi-line display is that the adopted HTML platform currently lacks the ability for us to use ellipsis to truncate at the end of multiple lines cleanly (although there are work-arounds!) The argument against the pop-up is that there really isn't much more information on an attachment than what we are already displaying without us getting very fancy. (Very fancy means doing a full download of small attachments like calendar data, or of the meta-data section of file formats where we can easily guess its location and we have server support for sufficient byte-serving.)
Eric is reviewing how other devices handle this. So far, as on Nexus, it appears long file names are just truncated, but he'll comment further after doing a bit more research.
(In reply to Stephany Wilkes from comment #5) > Eric is reviewing how other devices handle this. So far, as on Nexus, it > appears long file names are just truncated, but he'll comment further after > doing a bit more research. Looking on the galaxy S3 and iphone 5, they both truncate the text when the file name is too long. So this may be considered the norm. Another option I was thinking might work is to use the pop up that asks the user if they would like to save or view the attachment and displays the full name and file size (as described above by Andrew). But we can add the ability for the user to disable the pop in the future if they feel it's not needed. But as Andrew mentioned there isn't much we have to display in the pop up.
UX mentions the design is fine. blocking-