New issue
Advanced search Search tips
Starred by 20 users

Issue metadata

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

Sign in to add a comment

Issue 673199: Chrome 56 Disabled plugins get reenabled after browser restart

Reported by, Dec 12 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.21 Safari/537.36

Steps to reproduce the problem:
1. disable flash player in chrome://plugins
2. update to latest chrome beta
3. see flash player being reenabled

What is the expected behavior?
flash should stay dead.

What went wrong?
zombiefication of already disabled plugin. removal of PepperFlash folder causes it to be recreated, but empty - chrome says "internal-not-yet-present" for its location and obviously, it doesn't work. it still gets reenabled though.

Did this work before? Yes previous beta afaik

Chrome version: 56.0.2924.21  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:

Comment 1 by, Dec 12 2016

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

Comment 2 by, Dec 12 2016

Components: Internals>Plugins>Flash

Comment 3 by, Dec 19 2016

Components: -Internals>Plugins>Flash UI>Settings Internals>Plugins
Labels: Security_Severity-Low Security_Impact-Beta OS-Chrome OS-Linux OS-Mac
Status: Assigned (was: Unconfirmed)
pastarmovj: Would you mind taking a look at this? It seems like you've been making some changes to this code recently.

Comment 4 by, Dec 19 2016

 Issue 675384  has been merged into this issue.

Comment 5 by, Dec 20 2016

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.

Comment 6 by, Dec 20 2016

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.

Comment 7 by, Dec 21 2016

The enable/disable links are already removed (see 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.

Comment 8 by, Dec 21 2016

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.

Comment 9 by, Dec 21 2016

Status: WontFix (was: Assigned)
As per discussion marking the bug as wontfix.

Comment 10 by, Jan 26 2017

Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Security_Severity-Low -Security_Impact-Beta -Via-Wizard-Security Type-Bug
Removing wrong security labels from this bug.

Comment 11 by, Jan 26 2017

@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.

Comment 12 by, Jan 26 2017

See  issue 685597 
People are confused already

Comment 13 by, Jan 26 2017

 Issue 685590  has been merged into this issue.

Comment 14 by, Jan 26 2017

Status: Started (was: WontFix)
Can we merge 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.

Comment 15 by, Jan 26 2017

Labels: Merge-Request-56

Comment 16 by, Jan 26 2017

Project Member
Labels: -Merge-Request-56 Merge-Review-56 Hotlist-Merge-Review
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 - Your friendly Sheriffbot

Comment 17 by, Jan 26 2017

Summary: Chrome 56 Disabled plugins get reenabled after browser restart (was: Flash Player gets reenabled after browser restart)

Comment 18 by, Jan 27 2017

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".

Comment 19 by, Jan 27 2017

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: 

I suppose this bug I've already commented on is a duplicate then...

Comment 20 by, Jan 27 2017

Labels: -Merge-Review-56 Merge-Approved-56
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.

Comment 21 by, Jan 28 2017

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.

Comment 22 by, Jan 28 2017

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.

Comment 23 by, Jan 28 2017

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".)

Comment 24 by, Jan 29 2017

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...

Comment 25 by, Jan 29 2017

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

Comment 26 by, Jan 29 2017

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.

Comment 27 by, Jan 30 2017

+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?

Comment 28 by, Jan 30 2017

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.

Comment 29 by, Jan 30 2017

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!

Comment 30 by, Jan 30 2017

+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.

Comment 31 by, Jan 31 2017

Project Member
Labels: -merge-approved-56 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 32 by, Jan 31 2017

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.

Comment 33 by, Jan 31 2017

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).

Comment 34 by, Jan 31 2017

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

Comment 35 by, Feb 1 2017

Labels: TE-Verified-56.0.2924.87 TE-Verified-M56
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.


Comment 36 by, Feb 1 2017

Status: Verified (was: Started)

Comment 37 by, Feb 4 2017

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:
209 KB View Download

Comment 38 by, Feb 5 2017

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

Comment 39 by, Feb 10 2017

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.

Comment 40 by, Feb 10 2017

I fully agree with Comment 39

Comment 41 by, Feb 15 2017

 Issue 680386  has been merged into this issue.

Comment 42 Deleted

Comment 43 Deleted

Comment 44 by, Feb 28 2017

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.

chrome version:56.0.2924.87 (stable) (64 bit)

Comment 45 by, Mar 3 2017

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.

Comment 46 by, Oct 23 2017

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

Comment 47 by, Oct 25 2017

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.

Comment 48 by, Oct 25 2017

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.

Sign in to add a comment