to clarify, flash player gets reenabled after every restart on latest beta, not just once after the update.

pastarmovj: Would you mind taking a look at this? It seems like you've been making some changes to this code recently.

 Issue 675384  has been merged into this issue.

Technically with the latest changes to the plugins handling code all plugins will be in the "enabled" state as seen on the chrome://plugins page. 

You can now control the plugin availability though the contents settings section of the main chrome://settings page. If you select the "blocked" state then the plugin will not be available to any webpage. The pdf plugin is also controlled through there. All other plugins (NaCL and WideVine) are considered integral part of the browser and can not be disabled.

If this explanation covers the issue reported I will mark the bug as resolved.

to put it gently, it's complete nonsense from user point of view, imho.

what's the point of the option to disable them in chrome://plugins then? there's none.

i understand that that disable option may be just an alias for 'block everywhere', but even if that's the case, the whole change is just counter-intuitive. adding a link to chrome://plugins in settings page would be a lot better.

as for now, if there's no plan to revert this change, at least remove the enable/disable option from chrome://plugins altogether, because it makes no sense at all.

pretty please.

The enable/disable links are already removed (see https://bugs.chromium.org/p/chromium/issues/detail?id=615738#c44). You might as well want to follow the linked bug because it tracks the progress of the whole chrome://plugins deprecation. 

I am sorry about the confusion of this intermediate state. The change is rather large and took longer than a release to be accomplished.

nah, i'm just being bitchy about it. such situations are bound to happen though if you're removing something that more advanced users know and are using sometimes. i'm not arguing the general idea, it's just counter-intuitive for some people. not for most.

i also forgot that since i'm on beta, i may not have the latest changes.

thanks for the clarification.

As per discussion marking the bug as wontfix.

Removing wrong security labels from this bug. 

@pastarmovj, from comment 7 you mean the enable/disable links WILL BE removed.
For Stable 56 that is released in this "intermediate state", what are we going to tell confused users (eg. in Chrome discussion forum)?  "Sorry, but the FUTURE change is rather large and took longer than a release to be accomplished." ???

I agree wholeheartedly with @mirek that it's complete nonsense from user point of view.

The whole point of Chrome's fast development and release cycle is to allow quick updates.
If a change is not completely ready but it's in an intermediate state, then the whole thing should not have been released at all.

See  issue 685597 
People are confused already

 Issue 685590  has been merged into this issue.

Can we merge https://codereview.chromium.org/2530563002 in 56 for the next refresh? 

It was supposed to go in the same release but seems to have slipped in 57. It has been on master for quite a while now and is pure delete only CL.

This bug requires manual review: We are only 4 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop)

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

what's worse than confusion is that, in latest chrome beta (not sure about earlier versions - maybe i didn't notice), when flash is blocked in general and there are exceptions defined, set to "ask", it doesn't ask - it just launches flash without any confirmation/"click to play".

I used to disable flash from chrome://plugins because it's the only way on certain sites to force videos in html5, blocking flash through settings isn't enough since instead of the video, a square asking me to activate flash appears...

For instance: http://www.independent.co.uk/news/world/americas/donald-trump-carl-bernstein-republicans-emotional-voter-fraud-inauguration-count-a7547301.html 

I suppose this bug https://bugs.chromium.org/p/chromium/issues/detail?id=680386 I've already commented on is a duplicate then...

Tentatively approving for merge, there are grd changes removing text but we currently don't have a translation dump scheduled to update the corresponding xtb files.

@pastarmovj can you verify things still build/work as expected?  If that's the case it lgtm for merging.  Otherwise we can do a manual translation run on Monday.

Upvote for Comment 19
Since Chrome 56 I always get the square asking if I want to run the flash plugin - even on sites which have implemented a HTML 5 video player.

I have flash disabled since at least two years via chrome://plugins and now I have to watch videos via Flash instead of HTML 5 because I wont even come to the point to start the HTML 5 player because the square which asks me to run Flash "overrules" everything.
It's insane.

So probably what you should do is to tell websites that there is no flash installed so the HTML5 fallback gets triggered. And probably you have to detect if there is a HTML 5 version available and if yes don't show the square.
Or just remove the square, make a tooltip/popup (like when asking to save a password on or credit card) that there WOULD be flash content on this page and if you want to run it. So pages with HTML 5 would just work, and for pages which still need flash you could just click the tooltip.

Upvote for comment 19 and also comment 21.
I'm generally fine with retiring chrome://plugins, but then the replacement setting "Block sites from running Flash" should have the same effect as deactivating Flash under chrome://plugins.

Currently only the latter results in (almost all) sites immediately using (apparently fallback) HTML5 video instead of (click to run) Flash.

So if a site checks if Flash is present when loading a video and if setting "Block sites from running Flash" is enabled, Chrome should return the same payload as in the case when Flash is deactivated under chrome://plugins. ("Flash is not present" instead of "Flash is present and disabled, but user can click to run".)

About that, I found out that if you enable "chrome://flags/#prefer-html-over-flash" you can get the old behavior as if you disable flash in chrome://plugins, why it isn't enabled by default is beyond my comprehension...

Oh wait never mind, flash only videos are completely blocked that wait, I forgot.

Thank you, chrome://flags/#prefer-html-over-flash actually has the same effect as disabling Flash under chrome://plugins (I tried it with the link from comment 19) and I'll use that as a workaround in the meantime.

However, as you mentioned, flash only content is now completely blocked (as it was when disabling Flash under chrome://plugins). That's actually what I prefer, but it could be confusing for the average user. Maybe it's necessary to add a checkbox for this under the setting "Block sites from running Flash".

Alternatively, it could be enabled by default, but only applied for flash video content which actually has a HTML fallback.

+tommycli for the issue in c #19.

Tommy, afaik the "ask" setting should work as expected in this comment. Can you comment if this is right and if there is an issue here or wai?

m.kurz, markus.fuhrmann8: Yes, #prefer-html-over-flash in combination with BLOCK will get you the same behavior as disabling Flash via chrome://plugins did. #prefer-html-over-flash will be enabled by default very soon.

Apologies that there was a gap between when chrome://plugins disabling went away, and when #prefer-html-over-flash is enabled by default.

Julian: c#19-c#27 is an unfortunate side effect of the fact that we removed disabling Flash in M56, but haven't turned on Prefer HTML by Default yet.

It shouldn't affect this bug. This bug is just about the Disable link that doesn't do anything anymore. -- so I think just merge away!

+tommycli: Thank you for the clarification!

You might want to re-check if BLOCK + #prefer-html-over-flash has EXACTLY the same effect as deactivating chrome://plugins. 

So far I found at least one case where it makes a difference: The Photo Station on my Qnap NAS (not falling back to Flash, but still making a difference in the user interface for a video). As it's local access only, unfortunately I cannot provide a test link. However, that's an indication that Chrome returns different payloads if websites check for Flash availability.

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

commit fdacdd761288cc4be81ae5cecdda88413e36d106
Author: Julian Pastarmov <pastarmovj@chromium.org>
Date: Tue Jan 31 07:20:27 2017

Partial merge of https://crrev.com/b8e1ac73c904f3134c4be5fd978ef46de1b95279.

Remove the enable/disable links for the about:plugins page.

The partial merge only removes the links without touching the underlying
code to avoid merge conflicts due to dependency on another CL. Effectively
the result is the same.

BUG= 615738 , 673199 
TEST=manual
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
R=bustamante@chromium.org
TBR=bauerb

Review-Url: https://codereview.chromium.org/2659373002 .
Cr-Commit-Position: refs/branch-heads/2924@{#888}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/fdacdd761288cc4be81ae5cecdda88413e36d106/chrome/browser/resources/plugins.css
[modify] https://crrev.com/fdacdd761288cc4be81ae5cecdda88413e36d106/chrome/browser/resources/plugins.html

Does this affect corporate (MS-AD/ADMX) policies? "Click-to-Play" is enabled through GPO on all our installations.
You will very likely break our compliance needs with this change.

honzzze: The latest discussed change is a UI change only. (Removing dead UI). It shouldn't break any policies. (Assuming you are using DefaultPluginsSetting policy).

Thanks for the clarification! We'll have a look and eventually report if our policies aren't respected anymore.

Already verified this CL with reference to the CL in issue id: 615738.

Please refer the screencast attached in the issue id: 615738.

Hence, adding the verified labels.

Thanks...!!

Now I'm sure that BLOCK + #prefer-html-over-flash doesn't have the same effect as deactivating chrome://plugins

When clicking on an embedded YouTube video on Google+, Chrome tries to download the swf file instead of using the HTML5-player. You can try it with any video here:
https://plus.google.com/+tested

Deleted: Capture.PNG 209 KB

	Capture.PNG 209 KB View Download

It happens with firefox without flash too, guess it's a site issue...

The information in Comment 37 is correct.

"BLOCK + #prefer-html-over-flash" doesn't have the same effect as deactivating in "chrome://plugins" had.

Disabling the flash plugin in "chrome://plugins" put the browser in pure html5 mode. "BLOCK + #prefer-html-over-flash" leaves the browser in a mode where it reports a missing flash plugin and/or attempts to download flash elements.  This is horrible.

Can't the new logic for "BLOCK + #prefer-html-over-flash" just be put underneath the old "chrome://plugins" plugin disabling logic?  I'm having to run chrome 55 for development work now.  I hope this can be sorted out with some setting that gives pure html5 mode.  The "chrome://plugins" disabling logic was golden.  I just don't understand why it had to go.  The new logic is so annoying that I had to install a googleupdate killing rootkit so I can keep at chrome 55.  If no fix is coming, I have some ideas for a pure html5 mode add-on that doesn't involve user-agent changes.

I fully agree with Comment 39

 Issue 680386  has been merged into this issue.

I have same problems with Comment 18.In chrome:settings/content,Set option to "ask", it doesn't ask but launches flash automatically.Set option to "disable",it just block all of the flash content(some sites even popped up download dialog box and asked me to download flashplayer.swf).It is driving me crazy.My laptop is old and i hate to run all flash contents to make my laptop overheat and eat quite a bit of battery.
FYI,https://productforums.google.com/forum/#!topic/chrome/9oTF5VBxjDg

chrome version:56.0.2924.87 (stable) （64 bit）

To the user leaving Comment 44, the only chromium-based solution that provides true html5 mode is to run version 54.  It is clear that the logic being used now can't provide true html5 functionality.  An extension is under development but it will have to be a kludge, not as wonderful as the pure html5 mode in versions <55. 

And now there is also no chrome://flags/#prefer-html-over-flash in v61. Trying hard to remain respectful and constructive.

Yes, @Comment 46, in addition to killing off "chrome://flags/#prefer-html-over-flash", they also killed off "chrome://flags/#run-all-flash-in-allow-mode".  Now it is nearly impossible to run TV provider authentication where flash is mandatory, such as on cnbc.  The flash-based provider authentication cycles through about a dozen https domains, and it is tedious to discover them all and add them to the flash white list.  I'm now convinced that whoever forked the chrome Plugin UI in this manner... is the devil.  It is worse than torture to run chrome, both in html5 mode and if you need flash as well.  It was actually better overall when firefox was the monopoly browser.  Now we are stuck with this thing for ever how long non-app browsers are still supported.

the only devils are the devs still using flash on the web, and i'm saying that as a long time flash dev. considering flash player's security record, as well as the capabilities of current web browsers, flash needs to die, period.