Handle files of an unknown MIME type

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
6 years ago
8 months ago

People

(Reporter: jsmith, Assigned: fabrice)

Tracking

({feature})

unspecified
ARM
Gonk (Firefox OS)
feature

Firefox Tracking Flags

(b2g18+)

Details

(Whiteboard: [UX-P?] )

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Build: B2G 18 1/13/2013
Device: Unagi

Steps:

1. Visit content in the browser that's an unsupported content type

Expected:

We should get an error indicating that we couldn't load the content, as it's unsupported.

Actual:

We silently fail.
(Reporter)

Updated

6 years ago
tracking-b2g18: --- → ?
(Reporter)

Updated

6 years ago
Whiteboard: [UX-P?]
Jason, can you elaborate? When I visit a page that has an SWF, for example, I get a standard gray "A plugin is needed to display this content" box. Are you not seeing that? Or are you saying that we need something more?
(Reporter)

Comment 2

6 years ago
(In reply to Josh Carpenter [:jcarpenter] from comment #1)
> Jason, can you elaborate? When I visit a page that has an SWF, for example,
> I get a standard gray "A plugin is needed to display this content" box. Are
> you not seeing that? Or are you saying that we need something more?

Right. But this bug talks about a case such as when you visit content of an supported mime type.

Example - If I visit a link to exe file, we start loading and then nothing happens - we silently fail. What I'm suggesting here is that we don't silently fail if we try to load, say an exe link, but instead, we report some sort of error to the user that the content type being loaded is not supported on device.

So better error messages rather than silently failing then.
(Reporter)

Comment 3

6 years ago
(In reply to Jason Smith [:jsmith] from comment #2)
> (In reply to Josh Carpenter [:jcarpenter] from comment #1)
> > Jason, can you elaborate? When I visit a page that has an SWF, for example,
> > I get a standard gray "A plugin is needed to display this content" box. Are
> > you not seeing that? Or are you saying that we need something more?
> 
> Right. But this bug talks about a case such as when you visit content of an
> supported mime type.

Meant to say - unsupported mime type.

Example - visit http://mozqa.com/data/firefox/downloading/unknown_type.fmtd in the browser
Tracking, will consider an uplift if we can work around late-l10n.
tracking-b2g18: ? → +
(Reporter)

Updated

6 years ago
Duplicate of this bug: 800670
How should we handle files of an unknown MIME type? Should be display an error, or trigger a download via a web activity?

Either way this is going to need new platform support.
Flags: needinfo?(firefoxos-ux-bugzilla)
Keywords: feature
Summary: When visiting content that is an unsupported content type, show the user an error, don't silently fail → Handle files of an unknown MIME type
Whiteboard: [UX-P?] → [UX-P?], c=browser, u=user
Whiteboard: [UX-P?], c=browser, u=user → [UX-P?] c=browser u=user
(Assignee)

Updated

6 years ago
Assignee: nobody → fabrice
(Assignee)

Updated

6 years ago
Component: Gaia::Browser → General
Whiteboard: [UX-P?] c=browser u=user → [UX-P?]

Comment 7

6 years ago
Assigning to Rob since this one is tracking. Rob, feel free to reassign as needed or appropriate.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(rmacdonald)
Hi everyone...

This scenario is covered on pages 19 and 20 of the beloved "Previewing and Saving Transferred Files" pattern document - https://mozilla.box.com/s/ie6x8zgm8902dveyb5xf

Please flag me with your questions/concerns. :)

- Rob
Flags: needinfo?(rmacdonald)
(Assignee)

Comment 9

6 years ago
I can't access this mozilla.box.com url. Can we use public ones please?
Blocks: 848371
I can't access that spec either but I think we should just fire a VIEW web activity when we encounter a file of an unknown MIME type so that any app can offer to view it.

Comment 11

6 years ago
Hi Ben. I've fixed (I think) the Box access setting. Anyone with a link should be able to access it. Please let me know if you cannot. The spec referenced above is in this directory; you should see one PDF inside.
https://mozilla.box.com/files/0/f/867779242/Review

Comment 12

6 years ago
Created attachment 756611 [details]
Copy of the spec Rob mentions and that the Box link goes to
(Assignee)

Comment 13

6 years ago
One thing to decide is how we find what is a supported mime type. Currently gecko does something along these lines when you click a link to a resource from an html document:
- if this type is supported natively by the platform, we display it by navigating the page to this document. This is the case for images, videos, audio files (and pdf on desktop).
- then we check if we have an external app registered to handle the mime type.
- lastly, we prompt the user to know if we should just download the file.

In b2g, the situation is slightly different:
- Do we want any app to be navigated to a plain image/video/sound? This is ok in browser tabs only I think.
- The "external apps" for us are actually installed apps that offer a "view" activity (or "open" also like the gallery and music apps?), so we need to register handlers dynamically based on the apps available. We hardcoded that for pdf, but we need something better here.
- Lastly, when we have no app available, who is responsible for driving the download once the user accepts? This could be done mostly platform-side, using the existing download manager and relaying UI bits to gaia, or this could be 100% gaia.
(In reply to Fabrice Desré [:fabrice] from comment #13)
> In b2g, the situation is slightly different:
> - Do we want any app to be navigated to a plain image/video/sound? This is
> ok in browser tabs only I think.

I don't have a strong opinion on this, but what would you do other than display the media?

> - The "external apps" for us are actually installed apps that offer a "view"
> activity (or "open" also like the gallery and music apps?), so we need to
> register handlers dynamically based on the apps available. We hardcoded that
> for pdf, but we need something better here.

What needs to happen dynamically? Can you not just fire a "view" activity with the MIME type as a filter and let apps register for those types? (Sorry, it's a long time since I've looked at this code).

> - Lastly, when we have no app available, who is responsible for driving the
> download once the user accepts? This could be done mostly platform-side,
> using the existing download manager and relaying UI bits to gaia, or this
> could be 100% gaia.

I think this should be handled by the system app so that it can present UI in the notification tray about the status of the download (as per the UX specs), but I'm not sure how the download should get triggered.

Comment 15

5 years ago
(In reply to Fabrice Desré [:fabrice] from comment #13)
> - Lastly, when we have no app available, who is responsible for driving the
> download once the user accepts? This could be done mostly platform-side,
> using the existing download manager and relaying UI bits to gaia, or this
> could be 100% gaia.

I somewhat think that we should have a file manager gaia app that handles stuff like this (and file browsing/management/dialogs in general).
(In reply to Robert Kaiser (:kairo@mozilla.com) [away until early June] from comment #15)
> I somewhat think that we should have a file manager gaia app that handles
> stuff like this (and file browsing/management/dialogs in general).

I do think we need a file manager app, though I would prefer to call it a Downloads app to make it clear that it's for managing a flat list of the files you download from the web (saved in Device Storage), rather than accessing the whole hierarchical file system on the device.

But the reason I think the system app should handle the actual download process is that UX wants the UI to be in the system notification tray, with the ability to monitor the progress of downloads and cancel them if necessary.
Flags: needinfo?(jonas)
> In b2g, the situation is slightly different:
> - Do we want any app to be navigated to a plain image/video/sound? This is
> ok in browser tabs only I think.

Given that this is how all browsers behave, I think we should consider this normal web behavior. And since our apps are normal web, I think we should support this in apps too.

> - The "external apps" for us are actually installed apps that offer a "view"
> activity (or "open" also like the gallery and music apps?), so we need to
> register handlers dynamically based on the apps available. We hardcoded that
> for pdf, but we need something better here.
> - Lastly, when we have no app available, who is responsible for driving the
> download once the user accepts? This could be done mostly platform-side,
> using the existing download manager and relaying UI bits to gaia, or this
> could be 100% gaia.

Could we do something like this:
If we hit a resource that we can't natively render, display a WebActivity picker which contains the list of apps that support "view" of the selected file as well as a "download" option. If the user chooses "download" we trigger a browserAPI download event, otherwise we follow the normal WebActivity flow.

Has anyone asked the UX team for opinions?

(Why does gallery and music use "open" but everything else use "view"?? Something we need to clean up?)
Flags: needinfo?(jonas)
(Assignee)

Comment 18

5 years ago
The current plan is somewhat different... For resources we can't render we would fire a start-download event to the system app, that is then responsible for doing the download. Then we'll add UI to let the user "view" the file.

What you describe is close to what we do these days: we register "views" activities with their mime types and trigger them, but the apps are responsible for the download, and can't do it with the right cookie jar, and need the systemXHR permission.
Ok, that sounds ok. We definitely should get the UX team to come up with a comprehensive design at some point though, having to manage files that you've temporarily downloaded sort of sucks.

Once we have Stream support that will give us more options too.
(In reply to Jonas Sicking (:sicking) from comment #17)
> (Why does gallery and music use "open" but everything else use "view"??
> Something we need to clean up?)

The effort on bug 796729 to "sanitize web activities" had trouble reaching consensus/petered out and then it lost its then-necessary blocker-status.

The "open" activities were created to open existing Blobs, whereas our documented semantics for "view" at https://developer.mozilla.org/en-US/docs/WebAPI/Web_Activities just include a URL.  (And I think URL.createObjectURL, besides not working cross-document/process, would have really horrible semantics/lifetime issues even if it were made to work somehow.)

Can we normalize things so that implementing "view" should assume one or more of the following:

- url: The URL the data exists at or was fetched from. (This may include schemes not everyone could speak; like bit-torrent? or maybe an e-mail message id?  In order to allow de-duplication by apps like gallery where it's possible the UX flow could otherwise allow the user to create endless duplicates.)

- type: The MIME type of the data

- fileExtension or filename (like gallery already uses for open): The file extension/name of the file.  I'm suggesting this based on the recent "Re: Activity providers [Was: Re: Custom Ringtones]" thread on dev-gaia with Matěj Cepl.  The issue he faces is that most e-mail clients or web servers won't know the right MIME type for the file (text/x-ldif according to http://www.freedesktop.org/wiki/Software/shared-mime-info/).  And this seems to bear out; on my Ubuntu system, /etc/mime.types does not include a mapping.  So unless we create a WebAPI that is extensible by entries in manifest.webapp to let apps resolve the MIME types first, I think this might be a reasonable course of action.  I think having a regexp filter run against the url to look for a file extension in there might bring its own problems, such as cargo-culting of regexps to deal with weird URI schemes, etc.

- blob: The data, if already fetched.  So the app doesn't have to re-fetch it, etc.  Some de-duplication if it's a File stored in DeviceStorage and is known to the app may also be possible from this.
CCing Travis who's trying to coordinate cleaning up our WebActivities

Comment 22

8 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.