We have now disabled all plugins except Flash. But when a site attempts to use a plugin, we show "A plugin is needed to display this content." which is misleading to users. I'd like to follow the HTML spec here, which is that we show fallback content. Which may be empty, but empty is the best thing we can do here.

Note: since <embed> and <applet> don't have the opportunity for fallback content, these will always be invisible.

<applet> has the fallback content (see bug 1200602).

Comment on attachment 8798537 [details] Bug 1307445 part B - remove the gecko code that support :moz-type-unsupported and :moz-type-unsupported-platform, https://reviewboard.mozilla.org/r/83986/#review82570

Comment on attachment 8798536 [details] Bug 1307445 - Don't ever show "A plugin is needed to display this content." or "This plugin is disabled." - Just always use fallback content or empty content. https://reviewboard.mozilla.org/r/83984/#review82984 \o/ r=me for the toolkit pieces. I don't think I can review the Fennec bits with too much confidence, so requesting review from sebastian.

Comment on attachment 8798536 [details] Bug 1307445 - Don't ever show "A plugin is needed to display this content." or "This plugin is disabled." - Just always use fallback content or empty content. https://reviewboard.mozilla.org/r/83984/#review83516 LGTM. I'm not really happy about the empty fallback (I tested the patch with adobe's flash test page) but if that's what the spec wants us to do then I'm okay with it.

Hey bsmedberg - looks like you've got all the reviews you need here. Okay to land?

I have a few tests to fix up yet at https://treeherder.mozilla.org/#/jobs?repo=try&revision=3130c55a3745&selectedJob=28723646

Pushed by bsmedberg@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/0cfea99f8b46 part A - Don't ever show "A plugin is needed to display this content." or "This plugin is disabled." - Just always use fallback content or empty content. r=mconley+sebastian https://hg.mozilla.org/integration/mozilla-inbound/rev/d953aa5d64e7 part B - remove the gecko code that support :moz-type-unsupported and :moz-type-unsupported-platform, r=qdot

Pushed by bsmedberg@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/9725a29e47fb Fix merge conflict bustage for removed file from bug 1307445 part A.

https://hg.mozilla.org/mozilla-central/rev/0cfea99f8b46 https://hg.mozilla.org/mozilla-central/rev/d953aa5d64e7

This caused the browser_parsable_css.js test changes I made in bug 1221383 to be backed out, because after the changes here landed there's some unparsable CSS in toolkit/themes/shared/plugins/pluginProblem.css.

Comment on attachment 8802473 [details] [diff] [review] remove last CSS references to :-moz-type-unsupported, Review of attachment 8802473 [details] [diff] [review]: ----------------------------------------------------------------- More proof that this test is useful. :) Thanks florian!

https://hg.mozilla.org/integration/fx-team/rev/2a989bdc7edb1936d7f19639d88fc4be02bf812f Bug 1307445 - remove last CSS references to :-moz-type-unsupported, r=mconley.

The following png files were removed in latest Nightly Build(20161019030208), but still holding two links in pluginProblem.css. Is this intentional? - contentPluginMissing.png - contentPluginDownload.png - contentPluginDisabled.png [chrome://mozapps/skin/plugins/pluginProblem.css] :-moz-type-unsupported .icon, :-moz-type-unsupported-platform .icon { background-image: url(chrome://mozapps/skin/plugins/contentPluginMissing.png); } :-moz-type-unsupported .icon[installable] { background-image: url(chrome://mozapps/skin/plugins/contentPluginDownload.png); }

(In reply to Florian Quèze [:florian] [:flo] from comment #16) > https://hg.mozilla.org/integration/fx-team/rev/ > 2a989bdc7edb1936d7f19639d88fc4be02bf812f > Bug 1307445 - remove last CSS references to :-moz-type-unsupported, > r=mconley. I understand!

Reproduced the initial issue on Nightly 52.0a1 (Build ID: 20161004030204) on Windows 10 x64. Used the following websites: http://jgames.com/sudoku/? http://www.85play.com/unity-3d-games/30542/desert-claw-rising.html http://demos.telerik.com/silverlight/ Verified as fixed using Firefox RC 52 build 2 (Build ID: 20170302120751) on Windows 10 x64, Ubuntu 16.04 x64 and Mac OS X 10.11. The message "A plugin is needed to display this content" is no longer displayed. What I noticed is that there is no notification that plug-ins like Silverlight, Java or Unity are not supported anymore in Firefox 52. All I get when navigating to web pages that use the mentioned plug-ins is a link that I can use to download the plug-in. That is also kind of misleading for the normal user that could use a certain plugin in Firefox 51 and now is no longer able to. Benjamin, are there any future plans in regards to this?

No. The intentional behavior here is for Firefox itself to show no messages. If a website chooses to show a message, there's not a lot we can do about it.