830203 - Handle files of an unknown MIME type

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Jason Smith [:jsmith]]

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.

Comment 1

[Josh Carpenter [:jcarpenter]]

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?

Comment 2

[Jason Smith [:jsmith]]

(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.

Comment 3

[Jason Smith [:jsmith]]

(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

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

Tracking, will consider an uplift if we can work around late-l10n.

Comment 6

[Ben Francis [:benfrancis]]

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.

Comment 7

[Stephany Wilkes]

Assigning to Rob since this one is tracking. Rob, feel free to reassign as needed or appropriate.

Comment 8

[Rob MacDonald [:robmac]]

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

Comment 9

[[:fabrice] Fabrice Desré]

I can't access this mozilla.box.com url. Can we use public ones please?

Comment 10

[Ben Francis [:benfrancis]]

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

[Stephany Wilkes]

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

[Stephany Wilkes]

Attachment: Copy of the spec Rob mentions and that the Box link goes to

Comment 13

[[:fabrice] Fabrice Desré]

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.

Comment 14

[Ben Francis [:benfrancis]]

(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

[Robert Kaiser]

(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).

Comment 16

[Ben Francis [:benfrancis]]

(In reply to Robert Kaiser (:[e-mail]) [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.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

> 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?)

Comment 18

[[:fabrice] Fabrice Desré]

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.

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 20

[Andrew Sutherland [:asuth] (he/him)]

(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.

Comment 21

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

CCing Travis who's trying to coordinate cleaning up our WebActivities

Comment 22

[BMO Automation]

Firefox OS is not being worked on