Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Dealing with arbitrary blob types in "pick" and "share" web activities. Should we use application/octet-stream, application/*, stop filtering?

18 views
Skip to first unread message

Andrew Sutherland

unread,
Jul 22, 2014, 5:08:50 PM7/22/14
to dev-...@lists.mozilla.org
The email app currently filters the Blobs it accepts like so:
- share (serviced by the email app): { type: ["audio/*", "image/*",
"url", "video/*"] }
- pick (triggered by the email app): { type: ['image/*', 'video/*',
'audio/*'], nocrop: true }

There is a longstanding issue that our web activities are sort of an
evolved hodge-podge. The long-abandoned bug on this is
https://bugzil.la/796729.

Both activities have some edge cases:
- share: The browser shares with type "url", most other things seem to
use MIME type for blobs.
- pick: The contacts app uses "pick" to return non-Blobby things. It
filters on type:
["webcontacts/contact","webcontacts/email","webcontacts/tel","webcontacts/select"]

On a bug just duped to the canonical email bug https://bugzil.la/848400
it's been raised that the email app still does not have the ability to
attach arbitrary files. While this is not entirely true since we do
service the "new" activity with { type: "mail"} and support all Blobs
there, they are very different use-cases. I think we can probably
address this easily, but we either need to have some type of convention
to let us indicate that we are happy to receive arbitrary Blobs via
share or pick, but without running afoul of existing or new uses of
share/pick that would result in the email app doing something dumb
because it needs special logic. For example, the webcontacts/* results
are arguably nonsensical from the email app's perspective.

Viable options that come to mind that the email app and other existing
apps could advertise/support:
- Use the literal type "*/*" to indicate any MIME type with the
implication that the thing is a blob.
- type literal "application/octet-stream"
- type literal "application/*"
- type literal "blob" (or perhaps file since it would be nice to have a
filename attached or provided in parallel?)

Non-viable:
- Don't filter on type. I think this would only work for the share
activity;

Andrew

PS: Note that there are symmetry issues with downloading that are a
separate issue, see https://bugzil.la/825318

PPS: I am having deja vu on raising this issue, but I think it was
probably in some other context where the issue got lost or it was just
long ago. If you find where I raised it, please do reply so we can
chain the discussions together.
0 new messages