-internal must not be exposed to web content. The fact that some are exposed is a bad bug. -internal is not even a real vendor prefix.

I'm well aware of this but it is the only short term solution I can think of and it would only make us go from X to X+1 -internal exposed. The alternative is to discuss how a website can properly customise custom controls which is going to be quite fun to specify in a generic, cross platform and future forward manner :) This solution couldn't happen this year.

The short term solution is to disable this feature by default.

This merits an intent to ship, anyway. I am not sure why this just slipped into Blink (or even Chromium) without any announcement (chromium-dev also asks for intent to implement threads), especially if you contemplate having a pseudo element for it.

I think that a nodownload content attribute that removes that option from both context menu and media controls would make sense.

If other vendors agree, sure.
Perhaps a semantic solution can be cooked, such as specifying a normal license versus a open-style license using microdata (or maybe an opt in versus an opt out), making it a hint to which browsers that may adhere.

phistuck@, this feature just makes more obvious something that has been available for a long time. On desktop, right click on a video will offer "Save video as". Same goes on mobile with a long press. I agree that it is significantly more visible on mobile but I would be surprised if that really changes behaviour on desktop.

I am not inclined for developers to tell us that a video should not be downloaded because there are many ways one can do that. If they have the link to a file, they can download it and there is so much we can do about this. Hiding the download button sounds fine but pretending that we will prevent download sounds a promise we can't keep.

Note that we only offer this feature for proper files. When using MSE or HLS, the button should not appear.

The change here is that we are exposing the Downloads button, which was always available behind a context click (tap & hold). And Context Click *did* have a way to disable. 

We have to get data once the download buttons launch. We have given the heads up to some media properties and have received all clear / no feedback. As a result, we are on a holding pattern to wait and see more feedback. 

If we hear more feedback, we can triage this in the future. 

 Issue 675596  has been merged into this issue.

IMO having such a feature (the download button) should be controllable via API by webpage authors.
While a download function exists via context-menu, this download button is >1000 times more obvious.

And for some the concern has more emphasis on the blatantly obvious rather then on the more complex means of achieving a download. 

We will work on a solution for websites to have better control of the experience when using browser controls. Putting M-58 as an opportunistic target.

The same API or additional option in the same API should also disable "Save as" from the media player context menu.

In our mobile web app, we use the default controls. It turns out that this new download button doesn't work since we have a custom download feature and custom server architecture. So now I'm getting complaints about this new button appearing that doesn't work. I must have a way to hide the download button, or I'll be forced to create custom controls, something no one wants to happen.

Here's a screen shot showing the unwanted download button in the context of our mobile web app.

Deleted: unnamed.png 225 KB

	unnamed.png 225 KB View Download

And what problems does it cause that long-tap and "Save as..." does not?

The point is that the download button not in our design spec, and it doesn't work in our context, so therefore must be removed. I haven't tried long-tap and "save as..." but that probably doesn't work either. I don't mind if both features show and hide together, just so long as I can get the button hidden.

> The point is that the download button not in our design spec, and it doesn't work in our context, so therefore must be removed.

This. Putting a download button kinda has a "meaning" in a UI (in our particular case, the download button we put is used to download an hires version of the previewed video).

I understand the philosophy behind this change (make it even more easier for the end user to download a video), but it's too intrusive imho, and should have been optin (maybe a [download] attribute, with an optional alt-link [hires]).

All in all, permitting to avoid the "save as..." altogether seems like a benefit, but M-58 looks far away, a lot of us will have to put kludges in our css to work around this unfortunate mess...

Regards,

--jan

I am using the html5 audio control for streaming audio and that makes the download button extremely undesirable as there is no end to the file to be downloaded. Please provide a simple tag attribute like "nodownload" to remove this button. If it is visible most users will try it.

I guess one heuristic to add (to the "Save as..." context menu option as well as the download button) is that when there is no Content-Length (and the end of the file was not reached in terms of downloading it otherwise), the saving/downloading option should be disabled.

#20, #21 -
> The point is that the download button not in our design spec
Yes, well, if you decide to base your design specification on the native controls (I am certainly not advocating against it!), you are bound to have design changes, additions (a subtitle button was added, for example, out of the blue, even though your specified subtitle tracks before and nothing showed up), removals and even completely revamped controls with drastic color changes and you should take that into account.
(Regardless of a download button)

I've used this script to remove the right click capability from the media players. Still would love a simple option like download="disabled" for the HTML. Yes, I know folks can just look at the source, and get the media anyway.

<script type="text/javascript">
jQuery(document).ready(function(){
    jQuery('video').bind('contextmenu',function() { return false; });
});
</script>
<script type="text/javascript">
jQuery(document).ready(function(){
    jQuery('audio').bind('contextmenu',function() { return false; });
});
</script>

#24 - 

I always expected that the controls would be something you can do change the way you watch the video/audio, such is close captioning, full screen, play/pause, volume, playback position and even bitrate control. But "Downloading" actually breaks this flow, it has nothing to do with the video it self, it is a new kind of control.

I agree it might be useful, but I guess UI and UX wise, this button being shown by default is not helpful in most cases.

I can understand adding the feature by default, but there should be a way to turn it off. This feature is breaking my webapp.

+Jon 

The download button should be optional!

Sure, you can download anything that your browser can display, but that doesn't mean we should put a huge button right in front of everybody.

A download button infers permission to download the content, regardless of how easy it may or may not be to download without it. Please provide an option to remove this button

does anyone have a real solution for this????, this is a really bad update my clients are really mad with this

#31 -

Agreed. I think we've shown that this is a legitimate issue that needs fixing. Does anyone disagree with that?

Let's start talking about solutions.

I've already had complaints from users of my application. I give them an optional download icon in a caption area, so when they choose NOT to display that, they really don't want the browser to do them the "favor" of providing it.

We are working on a way for websites to disable the download buttons in addition to other buttons.

Again, I think the download button should be opt-in instead of opt-out (ie. not enabled by default), so developers don't have to change existing and legacy sites.

We should be able to configure the download button in two ways:

1) Download currently served video

   <video src=... download> (button downloads "src")

2) Specify an alternate download URL (hi-res version)

   a) Single source

      <video src=... download="/some/other/hd-video.webm">

   b) In case of multiple sources:

      <video download>
        <source src="foo.mp4" download="foo-hd.mp4" type="video/mp4" />
        <source src="foo.webm" download="foo-hd.webm" type="video/webm" />
        <source src="foo.ogg" download="foo-hd.ogg" type="video/ogg" />
      </video>

      (although I'm not sure about putting download on the video tag in case of multiple sources...)

I agree that this is most attractive schema. I would hate to see the return of CSS browser prefixes (-webkit-whatever), having happily rid my code of all of them only recently. They don't validate, and keeping track of them is a monumental pain.

My company implement a way to disable context click download for the videos. Videos are our product and this download button has not only made it easy for non-technical visitors to download our premium products, it looks like we are enabling it. Thanks a lot Chrome/Google.

Consider this a prelude to a cease and desist. You are requiring a time consuming, expensive code crisis for my company. I expect a solution to remove this button from your browser video player on my website.

Kat Caverly
The Greetums lady
ladyg@greetums.com

waiting for the fix

This Stack Overflow post gives a hack-type solution, but it does not work with dynamic sizing. Adding the ability to turn the download button on and off will be great.

Link to SO post: http://stackoverflow.com/questions/41115801/in-chrome-55-prevent-showing-download-button-for-html-5-video

This change has affected us in a negative manner.  The issue is that we use the native media player across different browsers for playing audio content for an online test.  We disable right-clicking on the browser window, and prevent the user from accessing the system where they are taking the exam, as well as clearing browser cache after each session.

However, having the download button present on the actual media player element has caused us a headache in that we are now looking at a different media library that is cross-browser and doesn't expose the download of the item.  We are required to prevent the student from being able to download any content, even onto the test system (and yes, I understand that they are downloading the content to the system's browser cache).

The media player interface should be just that--a player interface.  If a user wants to download content, they should right-click and Save As or whatever the equivalent functionality is on their applicable platform.

#40 - you can use Media Source Extensions for now - this disables the download button because it is regarded as streaming (even when it is not streaming).

#c41 - I'm not sure what's easier, implementing custom controls or video stream via MSA :)

*MSE

#42 - I am pretty sure that media source extensions are far easier (you simply fetch and append instead of setting as the video URL as the source, or something like that), but I do not have any experience with them.

#40 - I totally share your feelings. This is also a great troubles to my work as well. What we need is just a playing interface, and more features are NOT out concerns. It would be good if any changes on functionality would provide ways to disable it.

It's super broken in the context of streaming audio from an Icecast station. The "download" just goes forever until you cancel it.

#46 - I suspect Icecast streams can be easily identified (they have their own response pattern, ICY 200 something), so you might want to file an issue specifically for Icecast.

#47 - actually it's wrong. Only Firefox treats ICY 200 as equivalent HTTP-1.0 response. (as an exception). 
Chrome treats it as HTTP-0.9 and restricts to standard HTTP ports only (following recently discovered - 2016 - security vulnerabilities), while most Shoutcast streams work on other ports. 
Older Shoutcast servers suffer from this problem.
Newer Shoutcast servers work fine, as they use HTTP-1.0 responses. 
AFAIK Icecast also uses HTTP-1.0 responses, so this wouldn't be a valid criteria.

OTH another, more relevant, criteria would be the lack of "Content-Lenght" header, which, by nature, wouldn't be available / relevant for live content.

#48 - this still merits its own issue, as it is a different case than "it is downloadable, but we do not want the user to easily download it".

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=691561

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

commit caca06866f37c79df89cab9a634bb7497177236e
Author: avayvod <avayvod@chromium.org>
Date: Fri Mar 10 00:39:55 2017

[Blink, Media] Added controlsList to HTMLMediaElement

Adds a DOMTokenList backed controlsList/controlslist attribute to HTMLMediaElement with three keywords: nodownload, nofullscreen and noremoteplayback.

Spec change is discussed here: https://github.com/whatwg/html/issues/2293
Spec change PR is here: https://github.com/whatwg/html/pull/2426
WICG repo for the API is here: https://github.com/WICG/controls-list
Intent to ship is here: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/tFuQd3AcsIQ/discussion

BUG= 650174 , 685018 
TEST=manual+layout tests

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

[add] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/LayoutTests/http/tests/media/controls/controls-list-add-hide.html
[add] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/LayoutTests/http/tests/media/controls/controls-list-remove-show.html
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/LayoutTests/media/media-controls.js
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/LayoutTests/platform/mac/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/LayoutTests/platform/win/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/LayoutTests/virtual/stable/webexposed/element-instance-property-listing-expected.txt
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/LayoutTests/webexposed/element-instance-property-listing-expected.txt
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/BUILD.gn
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/HTMLAttributeNames.json5
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/HTMLMediaElement.h
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/HTMLMediaElement.idl
[add] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/HTMLMediaElementControlsList.cpp
[add] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/HTMLMediaElementControlsList.h
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/shadow/MediaControls.cpp
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/third_party/WebKit/Source/core/html/shadow/MediaControls.h
[modify] https://crrev.com/caca06866f37c79df89cab9a634bb7497177236e/tools/metrics/histograms/histograms.xml

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit 1f92e23e416a507c94523e120d1d4608b4ef087f
Author: Anton Vayvod <avayvod@google.com>
Date: Sat Mar 11 14:26:56 2017

[Blink, Media] Added controlsList to HTMLMediaElement

Adds a DOMTokenList backed controlsList/controlslist attribute to HTMLMediaElement with three keywords: nodownload, nofullscreen and noremoteplayback.

Spec change is discussed here: https://github.com/whatwg/html/issues/2293
Spec change PR is here: https://github.com/whatwg/html/pull/2426
WICG repo for the API is here: https://github.com/WICG/controls-list
Intent to ship is here: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/tFuQd3AcsIQ/discussion

BUG= 650174 , 685018 
TEST=manual+layout tests

Review-Url: https://codereview.chromium.org/2657723002
Cr-Commit-Position: refs/heads/master@{#455926}
(cherry picked from commit caca06866f37c79df89cab9a634bb7497177236e)

Review-Url: https://codereview.chromium.org/2741933004 .
Cr-Commit-Position: refs/branch-heads/3029@{#132}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[add] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/LayoutTests/http/tests/media/controls/controls-list-add-hide.html
[add] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/LayoutTests/http/tests/media/controls/controls-list-remove-show.html
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/LayoutTests/media/media-controls.js
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/LayoutTests/platform/mac/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/LayoutTests/platform/win/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/LayoutTests/virtual/stable/webexposed/element-instance-property-listing-expected.txt
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/LayoutTests/webexposed/element-instance-property-listing-expected.txt
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/BUILD.gn
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/HTMLAttributeNames.json5
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/HTMLMediaElement.h
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/HTMLMediaElement.idl
[add] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/HTMLMediaElementControlsList.cpp
[add] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/HTMLMediaElementControlsList.h
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/shadow/MediaControls.cpp
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/third_party/WebKit/Source/core/html/shadow/MediaControls.h
[modify] https://crrev.com/1f92e23e416a507c94523e120d1d4608b4ef087f/tools/metrics/histograms/histograms.xml

Fucking unbelievable that you landed this feature before there was a way to disable it, let alone that it took several months before you even aknowledged that it was an issue. It was so obvious.

Please find a way to disable the download button on html5 in Chrome. I understand that there are other ways to download something but most of them can be disabled. 
It is important enough that failing all, I am thinking of disabling my website on chrome and giving a message to go to other browsers

This has landed in Chrome 58, see https://developers.google.com/web/updates/2017/03/chrome-58-media-updates#controlslist 

Will this also apply to the <audio> tag? Same issue there.

Yes, it will apply to <video> and <audio>.

While glad that this is fixed and available in Chrome 58 (yet to be released as of this comment), I feel compelled to add that it is disturbing that such a feature would slip past scrutiny. While that's to some extent in the "forgive and forget" category, some of the comments on "we're just exposing what was always possible" feels hypocritical. <sarcasm>"Media properties" doesn't include youtube? We'd totally appreciate such a straightforward "download" button over there ;) </sarcasm>