839630 - Multiple mime types in pick MozActivity freeze Gallery UI for >10sec after cropping

Status: RESOLVED DUPLICATE of bug 834773

(Firefox OS Graveyard :: Gaia::Gallery, defect)

Description

[:Harald Kirschner :digitarald]

Starting a MozActivity "pick" and selecting the Gallery prompts the user to crop the selected picture. Not cropping, just confirming the checkbox blocks the UI without any feedback for ~10sec.

There might be a UX bug here that cropping should be skippable.

Comment 1

[David Flanagan [:djf]]

This came up the other day for someone else. The issue was that their moz activity was passing an array of mime types rather than a single mime type. Gallery doesn't know how to deal with this, and it ends up (somehow) creating a PNG image instead of a JPEG image.  A full-size photo as a PNG is really big, and the long freeze is the time it takes to create the image.

Please check your code to see if you're doing the same thing (passing an array of types instead of a single type).  Or to see if you're just requesting a PNG instead of a JPEG image.

Comment 2

[:Harald Kirschner :digitarald]

As others might run into the same problem, is that limitation expected and documented or is a bug tracked for it?

Why limit the mime types when your app allows every type? As a developer I'd expect that the picking app can have a preference on what it returns. A pixel-drawing app might prefer GIF, the photo gallery JPG and another app PNG. One app might just wrap Google Image Search and return whatever image it finds.

Comment 3

[David Flanagan [:djf]]

(In reply to Harald Kirschner from comment #2)
> As others might run into the same problem, is that limitation expected and
> documented or is a bug tracked for it?

As far as I know there is not a bug tracking it. Feel free to file one or assign this one to me and we can convert it to that.

> 
> Why limit the mime types when your app allows every type? 

The activities spec used to allow only one to be specified.  Gallery was written under the old spec.  Activities now allows an array of types. Someone has written some example code somewhere that unnecessarily passes an array of types to gallery which has not yet been updated to support that possibility.

As a developer I'd
> expect that the picking app can have a preference on what it returns. A
> pixel-drawing app might prefer GIF, the photo gallery JPG and another app
> PNG. One app might just wrap Google Image Search and return whatever image
> it finds.

Yes, and the app doing the pick can ask for whatever type it wants. But when it asks for multiple types, that is the part that Gallery doesn't know how to deal with. Its a trivial thing to fix in Gallery, just not very high priority right now.

Comment 4

[:Harald Kirschner :digitarald]

The joy of fast moving specs. I agree that its not priority. I assigned it to you for further conversion.

Comment 5

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

Supporing passing an array is mimetype is quite important. Generally applications don't care what image format they receive, they just want a file that uses the most appropriate encoding. Neither requesting "image/jpeg" nor "image/png" seems to produce that result (png's recoded to jpeg can also be quite inefficient and have artifacts).

Without this I don't really see how people are expected to use the "pick" activity?

Comment 6

[Jason Smith [:jsmith]]

In reference to comment 1 - Robert Nyman & myself were at least one set of the other people you are talking about. I didn't originally nom the bug, but I can nom it based on Jonas's argument.