Yeah, that's the same code path for the blob case and the download case (that's why I use a blob URL, so as to reuse all the code).

In fact, our QA already complained about showing the download screen when what's really doing is processing/extracting the download. What I was thinking on doing was just changing the literal that's shown for blobs so it said Processing instead of downloading.

On my tests I haven't seen the content length header, I can switch it back to the spinner if you prefer.

As for the download manager, when the content is sent with content-disposition attachment gecko doesn't launch the handler associated with the mime type. Instead it launches the download manager to download the file. After the download is finished the user can open/view the file and for that Gaia uses a WebActivity. To the activity it passes the local path of the file and a blob with the file contents.

What I did was use the path to get the file name (to set as the ringtone name or whatever) and process the data of the blob instead of reading the file again. And I use a blob URL, as I said, so the code for both cases (content-disposition inline where the actual download is handled by fl and content-disposition attachment where the download has been handled already) could be the same.


On 03/06/2014, at 23:58, "David Flanagan" <notifications@github.com<mailto:notifications@github.com>> wrote:


In apps/fl/js/download.js:

> @@ -365,13 +426,18 @@ function view(activity) {
>      download.send();
>
>      download.onprogress = function(e) {
> -      bar.value = e.loaded;
> +      if (hasDescriptor) {
> +        bar.value = e.loaded;
> +      } else {
> +        bar.value = (bar.value + 10) % bar.max;
> +      }


Are the servers really not sending the content-length header? If e.lengthComputable is false, then I can see that you would have to do this, but otherwise, I think you could do bar.value = e.loaded/e.total;

If you really know that you can never get content-length in this case, then you should use an indeterminate progress bar rather than using this % hack.

Also, is this the code path we take for the blob case? That seems like bad UX since the user has already seen the file download in the download manager, so they wouldn't expect to get another downloading progress bar, especially one that finishes almost instantly.

—
Reply to this email directly or view it on GitHub<https://github.com/mozilla-b2g/gaia/pull/19717/files#r13361628>.

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx