We don't show the download button for HLS and MSE.

I do not think the download button should be removed in cases where no Content-Length header is defined. It should not be an indication that a media is streamed, because misconfigured servers or naïve code may not set this header, despite the fact that the response really is a finite file. Suppressing this button for this case may hurt usability.

If you are going to use the no Content-Length header as an indication for that, perhaps show the download button only when the downloaded has finished.

*download

I mean, when the server has indicated that no more content is sent (the same indication that makes the download shelf mark a download as complete).

Mounir, there're apparently non-MSE/HLS infinite streams: "It's super broken in the context of streaming audio from an Icecast station. The "download" just goes forever until you cancel it."

Phistuck, we have some way of identifying whether the media stream can be seeked in the media pipeline which we could use (overloads of https://cs.chromium.org/chromium/src/media/base/data_source.h?rcl=28ff32abc83ae8939f56702151b3d982859d56b5&l=48).

I don't think we support saving buffered data at all (otherwise we would support MSE, for example) - the download is implemented by fetching the URL again.

I did not mean that you would support buffered media, but the fact that a response has ended might serve as an indication that it is not a stream, but a file.

But if you already distinguish seeked media, then this is perhaps moot...

I looked at the code you mentioned and unless I am missing something, it seems to distinguish a response as streaming if its range request fails, but I do not think this is enough.
https://cs.chromium.org/chromium/src/media/blink/multibuffer_data_source.cc?l=480
I already ran into such a server where the response came back as a file without Content-Length and range requests also did not work, but it was a finite file. It made Chrome not play the WAV file it returned as a result at all. Instead of fixing Chrome, the server was fixed. However, losing those cases will hurt usability, so I do not think the button should go away based on no-Content-Length-and-no-range-requests merits.

+dale

You want to disable downloads for any stream which reports an unknown file size to the data source; so we'll probably want to separate out the check of 200 vs 206 from unknown size and expose those as getters.

Assigning to avayvod@ since nominally you or mlamouri@ are the contact for downloads :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6920f2e6be77a44ee16b052b45b2c4228854ae0

commit b6920f2e6be77a44ee16b052b45b2c4228854ae0
Author: johnme <johnme@chromium.org>
Date: Tue Feb 21 22:17:06 2017

Media Controls: Remove download button for infinite streams

Specifically, removes the download button for media with infinite
duration, since there is no clear end at which to finish the download.

Also adds tests for the download button being hidden for empty URLs and
HLS streams, and fixes the test for the download button being hidden
when hideDownloadUI setting is disabled by making its video non-local.

BUG= 691561 , 654507 ,650738

Review-Url: https://codereview.chromium.org/2710713003
Cr-Commit-Position: refs/heads/master@{#451852}

[rename] https://crrev.com/b6920f2e6be77a44ee16b052b45b2c4228854ae0/third_party/WebKit/LayoutTests/http/tests/media/video-controls-download-button-not-displayed-hide-download-ui.html
[modify] https://crrev.com/b6920f2e6be77a44ee16b052b45b2c4228854ae0/third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp
[modify] https://crrev.com/b6920f2e6be77a44ee16b052b45b2c4228854ae0/third_party/WebKit/Source/core/html/shadow/MediaControlsTest.cpp

Hm, I don't think the change fully implements what Dale suggested in #c9.

Dale's suggestion would disable the download button for simple servers that fail to report Content-Length when serving files (as raised by phistuck).

b6920f2e6be77a44ee16b052b45b2c4228854ae0 adopted the more conservative scheme of disabling the download button for streams of infinite length (which I believe is usually determined from the media's metadata).

I tested this with Mounir, and this is sufficient to disable the download button on Icecast streams (your concern from comment 6), but avoids the issue phistuck raised.

Do you know of many infinite streams which fail to report infinite length?

Closing back as there was no follow up.

Would be nice if it solves https://bugs.chromium.org/p/chromium/issues/detail?id=650174#c18 too.

WDYM?

I meant that developer's use case for unwanted download button looks a lot like streaming - maybe this bug fix fixed their use case? There's no link though :/