Related UI decision:
https://bugs.chromium.org/p/chromium/issues/detail?id=622922#c63

Feel free to confirm with bettes@ on the latest visual decisions for Materialized settings if anything comes up.

(Though this is not recommended) - Enterprise users (and consumers) who want to preserve the "Allow" (always) behavior can add the following site exceptions for Flash:

"https://*" and "http://*" (setting them to Allow).

Note: These will not override sites that are explicitly blocked (i.e. a site that is affirmatively blocked will remain blocked, even with this global exception).

note : when testing with https://* as only ALLOW, and global set to BLOCK, I found that https://tv.xfinity.com played correctly, but that I still got a broken puzzlepiece icon in omnibox saying plugin was blocked.

may need to fix this as a separate bug.

Re-targeting to Chrome 61.

Did I say 61?  62 to give Enterprise enough time to message.

Per conversation with ericde --

ericde has cleared the enterprise hurdles... I'm going to take this bug over for a while to do the Settings implementation.

As part of this I'm also going to enable the PreferHtmlOverPlugins feature by default on Chromium, and in fact start removing codepaths to support the feature flag being off.

We still need the feature flag to stick around because we have a varations parameter (SEI threshold) associated with it... but we expect the flag to always be on.

Should we migrate users that have already changed their Flash content setting to ALLOW?

I'd vote No, as I don't think it's necessary.

They will get migrated to DETECT next time they visit the Flash settings page -- or when they reset their Profile.

At the least, I'd vote to defer migrating them until after we remove the HBD-off codepath, as we already have "legacy ask users" and confusion with ASK vs. DETECT. The content setting code for Flash is already very confusing, so I'm not keen on adding further migration logic.

chatted w/tommycli@ offline. 

SCENARIO : user on M61 has flash set to "ALWAYS ALLOW" & ASK disabled. user updates to M62. user never touches chrome://settings/content/flash. What should flash behaviour be?

DESIRED BEHAVIOUR : even never touches settings, default behaviour of Flash should become (or be interpreted as) ASK in above scenario. this would be similar to spec'd behaviour for DefaultPluginsSetting value of 1, which would now be the same as 3 -> ASK. It also aligns to our public commitment to removing the option to ALWAYS ALLOW. 

if user goes to chrome://settings/content/flash, they would see the setting as ASK.

RISK : interpret ALLOW as ASK could carry a bunch of edge cases/bugs that would require fixes later. 

COUNTER-RISK : having a behaviour (ALLOW) which cannot be set in 62 and is only possible to get to if you migrate & never touch flash settings is unexpected and undesirable.

Yes, chatted with ericde@.

We will migrate user behavior as well. I've given fair warning that I think this will be tricky.

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

commit 36cbc24e0e99afca6e45d8f791d0653eb566f0fb
Author: Tommy C. Li <tommycli@chromium.org>
Date: Thu Aug 03 01:09:32 2017

[HBD] Reduce tri-state Flash content setting to just ASK/BLOCK.

This only affects the UI, not the actual behavior, which will be in a
separate CL.

Users on ALLOW will remain on ALLOW unless they access the Settings UI.

Bug:  696790 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I27a0143f74d69d7985a0dd48645eab0bbc43193a
Reviewed-on: https://chromium-review.googlesource.com/599115
Reviewed-by: Dave Schuyler <dschuyler@chromium.org>
Commit-Queue: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491590}
[modify] https://crrev.com/36cbc24e0e99afca6e45d8f791d0653eb566f0fb/chrome/app/settings_strings.grdp
[modify] https://crrev.com/36cbc24e0e99afca6e45d8f791d0653eb566f0fb/chrome/browser/resources/settings/privacy_page/privacy_page.html
[modify] https://crrev.com/36cbc24e0e99afca6e45d8f791d0653eb566f0fb/chrome/browser/resources/settings/site_settings/category_default_setting.js
[modify] https://crrev.com/36cbc24e0e99afca6e45d8f791d0653eb566f0fb/chrome/browser/resources/settings/site_settings_page/site_settings_page.html
[modify] https://crrev.com/36cbc24e0e99afca6e45d8f791d0653eb566f0fb/chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc
[modify] https://crrev.com/36cbc24e0e99afca6e45d8f791d0653eb566f0fb/chrome/test/data/webui/settings/category_default_setting_tests.js

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

commit 2605a12d8c741a5044c0783eff973d0f0961c0bc
Author: Tommy C. Li <tommycli@chromium.org>
Date: Thu Aug 03 21:10:32 2017

[HBD] Enable kPreferHtmlOverPlugins feature flag by default

Since this feature is completely rolled out, beleatedly turn it on as
the default on Chromium.

Bug:  696790 
Change-Id: Id4b93d7d0882fb51e32326553b699b1ccbaf7e79
Reviewed-on: https://chromium-review.googlesource.com/599114
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Commit-Queue: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491844}
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/browser/content_settings/content_settings_browsertest.cc
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/browser/extensions/api/notifications/notifications_apitest.cc
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/browser/notifications/notification_interactive_uitest_support.cc
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/browser/notifications/platform_notification_service_interactive_uitest.cc
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/browser/plugins/chrome_plugin_service_filter_unittest.cc
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/browser/plugins/flash_download_interception_unittest.cc
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/browser/plugins/plugin_info_message_filter_unittest.cc
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/browser/prerender/prerender_browsertest.cc
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/browser/ui/content_settings/content_setting_bubble_model_unittest.cc
[modify] https://crrev.com/2605a12d8c741a5044c0783eff973d0f0961c0bc/chrome/common/chrome_features.cc

What's the plan for migrating existing users from ALLOW to ASK?

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

commit caac7d5c3334408cf9a80ccba87e36cebeadd43c
Author: Tommy C. Li <tommycli@chromium.org>
Date: Tue Aug 08 18:06:43 2017

[HBD] Clear all Plugins ALLOW-by-default content settings

We aren't supporting ALLOW-by-default in M62 and later. This implements
the cleanest solution of just clearing all ALLOW-by-default plugins
settings on startup.

Bug:  599115 
Change-Id: I6497a924732edf0af06ea10da394ab561d9d7842
Reviewed-on: https://chromium-review.googlesource.com/600522
Commit-Queue: Tommy Li <tommycli@chromium.org>
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#492697}
[modify] https://crrev.com/caac7d5c3334408cf9a80ccba87e36cebeadd43c/chrome/browser/content_settings/content_settings_default_provider_unittest.cc
[modify] https://crrev.com/caac7d5c3334408cf9a80ccba87e36cebeadd43c/components/content_settings/core/browser/content_settings_default_provider.cc

The above CL clears any ALLOW-by-default preference on startup.

I'm also working on another CL to interpret any ALLOW-by-default preferences as DETECT.

Those two in conjunction should effectively kill ALLOW-by-default.

\o/ awesome!

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

commit e669b8e8cd8d802fd1f842be94181f182ac4c698
Author: Tommy C. Li <tommycli@chromium.org>
Date: Mon Aug 14 20:47:18 2017

[HBD] Interpret Plugins ALLOW-by-default as DETECT-by-default

Bug:  696790 
Change-Id: I83e558a743901df710d9106dbd61fd0e5ce1a087
Reviewed-on: https://chromium-review.googlesource.com/607089
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: David Benjamin <davidben@chromium.org>
Commit-Queue: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494176}
[modify] https://crrev.com/e669b8e8cd8d802fd1f842be94181f182ac4c698/chrome/browser/content_settings/content_settings_browsertest.cc
[modify] https://crrev.com/e669b8e8cd8d802fd1f842be94181f182ac4c698/chrome/browser/plugins/chrome_plugin_service_filter_unittest.cc
[modify] https://crrev.com/e669b8e8cd8d802fd1f842be94181f182ac4c698/chrome/browser/plugins/flash_download_interception_unittest.cc
[modify] https://crrev.com/e669b8e8cd8d802fd1f842be94181f182ac4c698/chrome/browser/plugins/plugin_power_saver_browsertest.cc
[modify] https://crrev.com/e669b8e8cd8d802fd1f842be94181f182ac4c698/chrome/browser/plugins/plugin_utils.cc
[modify] https://crrev.com/e669b8e8cd8d802fd1f842be94181f182ac4c698/chrome/browser/prerender/prerender_browsertest.cc

Should be good now.

Excellent thank you!

ヘ( o^)ノ＼(^_^)

(High-five)