New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 34 users

Issue metadata

Status: Verified
Closed: Jan 2017
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug

Blocked on:
issue 628014
issue 654731
issue 654772
issue 662002
issue 667826

issue 641632

  • Only users with EditIssue permission may comment.

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 615738: Deprecate chrome://plugins

Reported by, May 30 2016 Project Member

Issue description

Objective: Remove the chrome://plugins page, moving configuration for the last remaining plugin, Flash Player, to it's own explicit place in content settings (including an option, in settings, to disable).

Rationale: This change should make the controls for Flash Player more discoverable, in settings (i.e. most users probably know what Flash is, but not what a "plugin" is), and will consolidate modes related to Flash Player (e.g. Plugin Power Savings mode), into a single location.

Supporting Rationale: Since we've deprecated NPAPI, Flash Player is now our last remaining plugin (i.e. 3rd party binary modules).  Those remaining "plugins" (PDF, CDM, etc...) started life as 3rd party code, but have since been built and maintained by Google... and at this point are effectively just specialized libraries for Chrome.

Comment 1 by, May 30 2016


Comment 2 by, Jun 1 2016

Just to track a small point: we still need a way for users/enterprise to always open PDF in an external PDF viewer. Currently this is achieved by disabling PDF either in chrome://plugins or via enterprise policy. This functionality should be retained, somehow.

Comment 3 by, Jun 1 2016

Components: -Internals>Plugins>Flash Internals>Plugins Enterprise

Comment 4 by, Jun 1 2016


Comment 5 by, Jun 2 2016

Labels: Enterprise-triaged

Comment 6 by, Jun 7 2016

Status: Assigned (was: Untriaged)
Please prioritize and assign.

Comment 7 by, Jul 8 2016

+bauerb, Julian - we were discussing other troubles originating from keeping chrome://plugins alive - Issue 625783

On #2 - should we have a FR to upgrade 'Always open PDFs outside Chrome' to the settings page? Any other proposal on that? 

That seems to be the only thing blocking this deprecation. Otherwise there seem to be multiple reasons to do it both from consumer and enterprise.

Comment 8 by, Jul 13 2016

Blockedon: 628014

Comment 9 by, Jul 19 2016

All green from my end.. the Blocked on bug for PDF does not have an owner but I believe that should be a pref backed by policy and not controlled from chrome://plugins any way

Comment 10 by, Aug 19 2016

Hey, groby@ and I were looking at the HBD project, and we have the following Settings Migration items:

Always Allowed to Run => Content Settings ALLOW
Disable => Content Settings BLOCK

Enterprise Policies:
DisabledPlugins contains “Shockwave Flash” => Content Setting BLOCK and Grayed out
PluginsAllowedForUrls, PluginsBlockedForUrls : Populate Content Setting BLOCK/ALLOW list

These settings relate to chrome://plugins. I was wondering if you guys are planning to migrate these Settings as part of this chrome://plugins deprecation project.



Comment 11 by, Aug 26 2016

Labels: -M-54 M-55

Comment 12 by, Aug 27 2016

Blocking: 641632

Comment 13 by, Aug 29 2016


Comment 14 by, Sep 13 2016

Labels: -Pri-2 Pri-1
is this still on track for M55?

Comment 15 by, Sep 14 2016

A few thoughts about custom plugins that I just wanted to make sure we've thought through:

People can load custom pepper plugins via command line flags. Enterprises, for example, may do this to achieve some kind of integration with the browser. If we change all of the plugins settings in Chrome to be flash-specific, we will be removing the ability to manage custom plugins in the Chrome UI. For example, enterprises will not be able to whitelist their plugin for a specific set of sites. 

Is this functionality that is important to preserve or are we knowingly removing these capabilities? Or maybe things like enterprise settings will still effect all plugins?

Comment 16 by, Sep 14 2016

Agree with raymes above. We will be losing the ability to manually enable/disable custom plugins, as well as site exceptions for those plugins.

I think... in terms of enabling/disabling custom plugins, enterprises can choose to include or not include those custom plugins on their command line.

In terms of site exceptions for their custom plugin - as the code currently stands, the Allow / Block / Detect content settings still apply to all Plugins, not just Flash. We will probably need to change that.

Could an enterprise running a custom plugin just implement the site-restrictions within the plugin implementation itself?

Comment 17 by, Sep 17 2016

Tommy's analysis/ summary looks correct to me. 

Some additional thoughts:

- Enterprises can still continue to manage these on the command line (i.e. the UI likely wasn't providing value - since it wasn't the user managing them).

- Site exceptions probably don't mean much, if they are manually forcing these plugins on (i.e. the design of the "plugin" blocking is really pretty Flash centric at this point).  As an example, which came from us, we've excluded other things like PDF and CDM because it was undesirable to block them (i.e. having the same policy produced very odd side effects in places like print preview).  My suspicion would be that any side loaded plugin would be of a similar nature to PDF/ CDM.

- Perhaps not in this round, but we should probably lock down the ability to inject 3rd party plugins into Chrome. I don't know if that's something that we necessarily want to support indefinitely.

Comment 18 by, Sep 23 2016

CC myself since the CDM is also on chrome://plugins page.

Comment 19 by, Sep 23 2016

Hey xhwang:

I did have a question. I noticed something called Pepper CDM / Clearkey CDM [1].

That's does not seem to be treated as JavaScript under Content Settings yet. Will it be a problem if it is?

Also what's the relationship between that Pepper CDM / Clearkey CDM and Widevine?



Comment 20 by, Sep 23 2016

Pepper CDM refers to a CDM that is registered as a pepper plugin. In Chrome, the plugin is implemented by PpapiCdmAdapter, which will load the real CDM binary at run time.

We have two types of pepper CDM right now:
- Widevine CDM: used in production; registered internally
- Clear Key CDM: for test only; registered through command line in tests

For background on why the CDM use JavaScript settings instead of plugin settings, see issue 178654.


Comment 21 by, Sep 23 2016

Project Member
The following revision refers to this bug:

commit d9adeff125559612a223819de5fce36c5e337b4f
Author: tommycli <>
Date: Fri Sep 23 18:20:05 2016

[HBD] Merge two identical ShouldUseJavaScriptSettingForPlugin impls

We are probably going to change this soon to only use the Plugin
content setting for Flash. Before that, we should merge these two
identical implementations so we don't have to change it in two places.

BUG= 615738 

Cr-Commit-Position: refs/heads/master@{#420666}


Comment 22 by, Sep 28 2016

Project Member
The following revision refers to this bug:

commit 5bd02f157d55ecf5c4c97b1161dd4fb5208d0be0
Author: tommycli <>
Date: Tue Sep 27 21:53:08 2016

[HBD] Only use Plugin Content Settings for Flash.

All other plugins (PDF, Widevine, Nacl), as well as custom plugins,
should be treated as JavaScript.

This is because starting in 55, all the Plugin content settings UI
surfaces have been renamed the Flash content settings.

This is related to the chrome://plugins deprecation.

BUG= 615738 

Cr-Commit-Position: refs/heads/master@{#421348}


Comment 23 by, Oct 11 2016

Blockedon: 654731

Comment 24 by, Oct 11 2016

Blockedon: 654772

Comment 25 by, Oct 17 2016

given that we're beyond M55 branch, is this now targeted for M56?

Also, there is concern that if a user had disabled the Widevine CDM in chrome://plugins, and we remove that page, does CDM still remain disabled, or have we removed that code already that allows CDM to be enabled/disabled via chrome://plugins?

Comment 26 by, Oct 17 2016

I am about to land the CL ( which will make the old plugin related policies only translate into the new pdf and flash related policies. Any other plugin disabled through policy will be ignored. However the user choices will be preserved.

Imho postponing for 56 if there is no hard reasons not to would give us enough time to make sure all the loose ends are tied.

Comment 27 by, Oct 17 2016

Labels: -M-55 M-56
Let's punt to 56.

Comment 28 by, Oct 17 2016

(Re #26) pastarmovj:

Could you please clarify on this statement? 

"Any other plugin disabled through policy will be ignored. However the user choices will be preserved."

Does this mean if a user has disabled the CDM previously, after chrome://plugins is removed, the user will actually be able to use/load the CDM, which will bypass the policy/setting?

When you say "user choices will be preserved", do you mean the content setting will not be changed, but we will not check it when loading the CDM?

Comment 29 by, Oct 17 2016

I mean that the policies which cover those prefs are not connected to them anymore - which means that if the Admins were using those policies they will not block CDM for example. However the prefs are still present and respected by the plugins code which means that if a used has went into the about:plugins page and disabled a plugin manually it will still be disabled. The plan is to completely remove those prefs but I didn't want to do this after the branch point.

All in all it will be all-round cleaner if we punt to 56.

Comment 30 by, Oct 17 2016

Cool. Just to make it clear, after about://plugins goes away, if the CDM was previously disabled by user, it should become enabled. Otherwise, user will stuck in the disabled state forever since there's no way to reenable it. Does this make sense?

Comment 31 by, Oct 17 2016

per #30 : CDM should always be enabled. it should have never been "disable"-able, regardless of the CDM setting. 

That being said, for Flash, the story is as you describe in #29 (if disabled by user, it should still be disabled).

Comment 32 by, Oct 17 2016

Re: 31

On Chrome stable M54 (54.0.2840.59 m (64-bit) Windows 10) when I click 'disable' for the Widevine CDM component in chrome://plugins - netflix breaks with Error Code: M7701-1003 "We cannot find all the required components to play Netflix on this device. Please visit chrome://components, locate the WidevineCdm component, and click the "Check for update" button."

Clicking 'Enable' and reloading netflix causes this error to go away. So I think it is possible to disable CDM.

Comment 33 by, Oct 17 2016

I think what ericde@ said is "it SHOULD HAVE never been 'disable'-able"...

Comment 34 by, Oct 18 2016

After the transition away from about:plugins Widevine will become enabled for everyone unless they delete it somehow or use the no binary component updates policy to prevent it from appearing in the first place.

As for manually disabled Pdf or Flash viewer the setting will be preserved in the content settings prefs that are successors to the old plugin prefs (unless those are already set manually in a conflicting state).

Comment 35 by, Nov 3 2016

Blockedon: 662002

Comment 36 by, Nov 16 2016

Hi guys, I put all the pieces needed to port the old plugin prefs into the new settings. Now it's back at you to remove the page if you think we are good to go with this now.

Comment 37 by, Nov 16 2016

Is 662002 fixed?

Comment 38 by, Nov 17 2016

The actual migration code is in. I am going to commit one more clean-up CL in the following days but no more logic is needed to accomplish the pref migration.

Comment 39 by, Nov 21 2016

Now that  is closed and the code that was triggered by the "Enable"/"Disable" buttons on the about:plugins code is noops we should make sure to remove that page before the next branch point.

I will leave it to Tommy and the tpms to decide if you want to backmerge any of that to 56 or leave it at 57.

Comment 40 by, Nov 21 2016

Since the bulk of the work is done, if possible we should try and get this ported back into M56 (Jan).  I'd like to avoid making Flash changes while we are in the process of ramping up HBD.

Comment 41 by, Nov 22 2016

Sure, but let's first have the CL that removes the about:plugins page done before we merge any of those on the branch. This way it will be certainly all or nothing.

Comment 42 by, Nov 22 2016

Blockedon: 667826

Comment 43 by, Nov 23 2016 (in review) is handling the removal of the enable/disable links as precursor to the full deprecation.

Comment 44 by, Nov 24 2016

Project Member

Comment 45 by, Dec 13 2016

Labels: TE-Verified-57.0.2950.0 TE-Verified-M57
Tested the issue on windows 7, Mac 10.11.6, Linux Ubuntu 14.04 using chrome Canary version 57.0.2950.0 as per Comment#44.Observed Enable/Disable links are removed for the about:plugins page.

Please find the attached screen cast for the same.

Adding TE-Verified labels.

268 KB View Download

Comment 46 by, Dec 13 2016

This looks about right. Thanks! :) 

You could also try to expand the "details" (the link at the top-right) and make sure no enable/disable links are present on individual plugin files too. You don't have to upload a video if the result looks the same.

Comment 47 by, Dec 13 2016

Just to double check, if previously a plugin was disabled, will it be enabled by default after Enable/Disable links are removed? Otherwise there's no way to enable it IIUIC.

Comment 48 by, Dec 14 2016

Re #47: Even better - the state be preserved in a place that you can reach and change - the state of the PDF plugin is transformed in the new content setting for PDF (e.g. it will be set to open PDFs externally if the plugin was disabled). The state for flash is preserved in the content setting for flash (e.g it will be set to block if the plugin was disabled). Any other plugin will simply be re-enabled because it was never meant to be disable-able in the first place.

Comment 49 by, Dec 14 2016

That sounds really great. Thanks!

Comment 50 by, Dec 21 2016

 Issue 673373  has been merged into this issue.

Comment 51 by, Dec 28 2016

Blocking a plugin is not the same as deactivating one. When blocked it asks to unblock, if deactivated it uses an alternative. So merging  Issue 673373  doesn't seem right.

Comment 52 by, Dec 28 2016

Re #51: If you wish to discuss if blocking the plugin is not sufficient for your use case this is still the right bug to do this as it captures the work around plugins management.

Comment 53 by, Dec 28 2016

Just to give an example, when I visit with a blocked Flash plugin it offers me to unblock it, with a deactivated plugin it offers me a way to the Beta site which works w/o Flash.

That is why I want to deactivate Flash, because many sites still have Flash as default, HTML5 as alternative.

Comment 54 by, Jan 3 2017

thbohn, we are actually changing to that behavior by default (called "HTML5 by default") for all websites :)

Comment 55 by, Jan 3 2017

To verify: we'll still be able to set "always allowed to run" on Flash even with HTML5 By Default is enabled in the new content settings for flash, yes? Will that option be settable via the admin console for managed devices? 

(We have a use case wherein if 'always allowed to run' for flash is not checked in the current chrome://plugins but HTML5 By Default is enabled, flash will not be detected and flash content on this one educational website will not load at all.)

Comment 56 by, Jan 3 2017

Addendum to my question: I see a policy for users for DefaultPluginsSetting, but nothing under Public Sessions settings. We need to be able to force flash to 'always allowed' in public sessions.

Comment 57 by, Jan 3 2017

@jsmith - Yes, setting (via policy) the DefaultPluginSetting(1) to 1 will accomplish what you are looking for.

Please note that there are some very significant security (and privacy) implications/ concerns (2) related to turning Flash Player on to always run, I'd advise also exploring PluginsAllowedForUrls (3) to explicitly select which urls are permitted to run Flash Player and block everything else.  It's a bit more work to administer, but it ultimately limits Flash to only running on vetted and trusted sites.

(1) -
(2) -
(3) -

Comment 58 by, Jan 4 2017

re #57: yes, PluginsAllowedForUrls is a bit more work for us (a school), but will work and is obviously the 'better' choice. However, that option is only for User Sessions, not for Public Sessions, which is a huge issue for us. (public sessions are easier for younger kids.)

Comment 59 by, Jan 4 2017

Further testing confirms: if I put [*.] into PluginsAllowedForUrls under User Settings, works. However, there is no PluginsAllowedForUrls in Public Session Settings.

Comment 60 by, Jan 4 2017

@jsmith, thank you we appreciate the feedback, although it's a little off topic for this issue (i.e. the presence or absence of chrome://plugins won't affect the behavior of public sessions).

If you could please file a separate issue for the request to add plugin policy controls for public sessions, we can at least have our Enterprise + Chrome OS folks take a look at it to see if it's something that they would want to prioritize.

Comment 61 by, Jan 7 2017

Yesterday I found on the flag site: Prefer HTML content by hiding Flash from the list of plug-ins. #prefer-html-over-flash

This is what I was looking for.

Comment 62 by, Jan 11 2017


Comment 63 by, Jan 11 2017

Was chatting with Julian about whether we still need the Disabled Plugin placeholder now that chrome://plugins is going away.

Looks like if you disable PDF via content settings and use an <object>/<embed> tag without fallback content, we still trigger it. 

See screenshot from the second test case here:

What's the desired behavior? Should we download the PDF in that case like we do for <iframe>? Or should we just modify the disabled plugin UI to show "Chromium PDF Viewer disabled" and remove the "visit chrome://plugins" portion?

I'd recommend downloading the PDF... but I'm not sure how hard this is.
Screenshot from 2017-01-11 13:56:55.png
37.5 KB View Download

Comment 64 by, Jan 12 2017

Thanks for looking into this.

Depending on complexity/ time, having some way to download that content would be ideal (perhaps via a link in the placeholder - i.e. without triggering a drive by download).

My suspicion, given the timing of the Chrome 57 branch point, we might want to start w/ the most expedient approach of simply removing the "visit chrome://plugins" text. If we can do something more advanced, you've got my support.

Comment 65 by, Jan 13 2017

Project Member
The following revision refers to this bug:

commit cc44547a90acfb170c5a52be637009c6940745ca
Author: tommycli <>
Date: Fri Jan 13 16:51:05 2017

Plugins: Remove left over references to chrome://plugins

Removes the chrome://plugins link from the Disabled Plugin placeholder. It doesn't work anymore.

BUG= 615738 

Cr-Commit-Position: refs/heads/master@{#443581}


Comment 66 by, Jan 13 2017

Status: Fixed (was: Assigned)
Cool. This is finished. I'm marking this fixed, and tracking the PDF placeholder edge case in this bug:

Comment 67 by, Jan 26 2017

 Issue 671029  has been merged into this issue.

Comment 68 by, Jan 31 2017

Project Member
Labels: merge-merged-2924
The following revision refers to this bug:

commit fdacdd761288cc4be81ae5cecdda88413e36d106
Author: Julian Pastarmov <>
Date: Tue Jan 31 07:20:27 2017

Partial merge of

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 

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


Comment 69 by, Feb 1 2017

Labels: TE-Verified-M56 TE-Verified-56.0.2924.87
Verified the fix on Mac 10.12.2, Win-10 and Ubuntu 14.04 using Chrome version #56.0.2924.87 as per the comment #68.

Observed that Enable/Disable links are removed for the about:plugins page.

Hence, the fix is working as expected.

Attaching the screencast for reference.

Adding the verified labels.

1.1 MB View Download

Comment 70 by, Feb 3 2017

Dear Googler,

I love Chrome, but this change SUCKS!

I have had Flash disabled permanently in my chrome://plugins settings. This is not the same as using the configuration at chrome://settings/content. With old Chrome behavior (until version 55) websites were told that I have no Flash Player, thus they were forced to deliver me the HTML5 version (which works almost everywhere). With new Chrome behavior (since version 56) websites are told that I have Flash Player, even if I have disabled Flash at chrome://settings/content, and so I see lots of Jigsaw pieces instead of perfectly working HTML5 content.

I guess you won't revert your decision, but please, please fix at least the behavior to tell websites that the Browser ships Flash while it is disabled in Chrome.

By the way, the changes not only broke my HTML5 experience, but also PDF. I use Chrome as my standard PDF reader, also for PDFs on my hard drive. For whatever reason the update to Chrome 56 disabled the Chrome PDF reader (because it activated the "use standard PDF reader" in chrome://settings/content . With Chrome BEING the standard PDF reader, this sends PDFs into a circle of "downloading" - Chrome sending file to Windows - Windows sending file to Chrome.

Comment 71 by, Feb 3 2017

Guenther, starting in M56 html5 is supposed to be chosen by default over Flash content, see
So this features intention matches yours, but the implementation may not have considered all corner use cases. Could you please confirm that in settings "Do not allow any sites to use a plugin to access your computer" is checked? With that CNN (for instance) serves html5 video to me and sites that don't have a fallback show the jigsaw. (You may also may check chrome://site-engagement/ and change scores there to 0 if you are inclined to troubleshoot the problem further.)

For the PDF problem you may want to file a new issue.

Comment 72 by, Feb 3 2017

and if you truly want to completely disable Flash (including having it act as if it's not there per ihf@'s comment in #71), you can goto chrome://settings/content and set Flash to "Block sites from running Flash".

Comment 73 by, Feb 3 2017

Dear IHF (comment #70),

thank you for your quick response.

In both the "unsandboxed plugin access" as in the "Flash" section of chrome://settings/content, the respective third option is activated (and always was). As I can see on, Flash is among the plugins that are presented to websites as installed. Only if I enable manually prefer-html-over-flash in chrome://flags/ (which I haven't touched until today), the information about Flash is gone in my browser fingerprint.

Therefore it is incorrect that just choosing "Block sites from running Flash" would make Chrome behave as if Flash wasn't there at all. I would be happy if it did.

Comment 74 by, Feb 4 2017

Gunther : as ihf@ communicated (and I believe you tried this with Prefer HTML and confirmed), we will begin rolling out "Prefer HTML5" by default now that M56 is released to stable channel. What you found when you enabled this (chrome acts as if Flash isn't available -> as evidenced by navigator.plugins & navigator.mimetypes not advertising support for Flash. 

It's OK for you to keep this flag set to ENABLED, and even further if you set Flash to BLocked, it will always act as if Flash is blocked in this manner,  which will signal to sites to use their HTML5 fallbacks if they have them.

Comment 75 Deleted

Comment 76 by, Mar 17 2017

Hi, I am probably ignorant but does this change affect shockwave? Or do The flash setting mirror the setting for shockwave. Basically is there a way to get shockwave working in chrome?

Comment 77 by, Mar 18 2017

Labels: Restrict-AddIssueComment-EditIssue
Hi Nathan,

This article should help you find more info about troubleshooting Flash Player:

Comment 78 by, May 17 2017

Status: Verified (was: Fixed)
As verified in M60.0.3101.0:9557.0.0 dev caroline and glimmer, the chrome://plugins page has been removed and no longer accessible.

Sign in to add a comment