User Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release) Build ID: 20130910160258 Steps to reproduce: 1. I go to a page that has many embedded flash items. 2. I right-click on the one I want to play and check it comes from a trustworthy source. (Such as YouTube.) 3. I click the "Activate Flash" button. A message box asks me to confirm. I select allow. Actual results: All of the flash code on the page runs, not just the one thing I trusted. Expected results: Only the one thing I had selected should have played. The last version of Firefox had it exactly right. Each flash item had it's own "play" button and you could click the blue icon next to the URL text box if you wanted everything on the page to run. Requiring users to choose between trusting everything or trusting nothing on a page is a step back. Please bring back the old way at least until the JS based flash player is ready and I can get rid of the Adobe player once and for all.

I can reproduce this for Firefox 24+. However, given the facts that 1.) the behavioral change in FF24 was intentional (so somebody must have liked it), and 2.) a lot of people like the older FF23 functionality better (see below), I'd suggest to make it optional. In detail, I suggest to introduce a user option to make click-to-play affect a) only the clicked element (as until FF23), b) all instances on the current page, or c) all instances on the entire website (as in FF24+). In addition, it should be configurable that enabling a plugin holds a) only for the current single visit of the page (as until FF23), or b) for a certain number of hours/days (as in FF24+). This should satisfy the different needs of different users. Personally, I like the FF23 way (click to play works per-element and per page visit) much better than the new way; mainly because of security concerns: I usually know which exact plugin instances I want to activate, and I want all other instances to stay inactive so they cannot harm my system. I guess that the users of the "Click to Play per-element" extension (https://addons.mozilla.org/en-us/firefox/addon/click-to-play-per-element/) have a similar preference, but this plugin does no longer work for FF26. Anyway, I think this issue should rather be solved at its root (= directly within FF) instead of an extension.

I think the recent news that Yahoo users were being shown malicious Java via a third party advertisier is a perfect case in point why it should be per-element instead of per-page. http://www.washingtonpost.com/blogs/the-switch/wp/2014/01/04/thousands-of-visitors-to-yahoo-com-hit-with-malware-attack-researchers-say/ I might trust Yahoo's Java apps, but certainly not the Java found on the 3rd party ads, which will all be on the same page.

(In reply to Spampot from comment #1) > I can reproduce this for Firefox 24+. However, given the facts that > 1.) the behavioral change in FF24 was intentional (so somebody must have > liked it), and > 2.) a lot of people like the older FF23 functionality better (see below), > > I'd suggest to make it optional. In detail, I suggest to introduce a user > option to make click-to-play affect > a) only the clicked element (as until FF23), > b) all instances on the current page, or > c) all instances on the entire website (as in FF24+). > > In addition, it should be configurable that enabling a plugin holds > a) only for the current single visit of the page (as until FF23), or > b) for a certain number of hours/days (as in FF24+). > > This should satisfy the different needs of different users. Personally, I > like the FF23 way (click to play works per-element and per page visit) much > better than the new way; mainly because of security concerns: I usually know > which exact plugin instances I want to activate, and I want all other > instances to stay inactive so they cannot harm my system. I guess that the > users of the "Click to Play per-element" extension > (https://addons.mozilla.org/en-us/firefox/addon/click-to-play-per-element/) > have a similar preference, but this plugin does no longer work for FF26. > Anyway, I think this issue should rather be solved at its root (= directly > within FF) instead of an extension. just found this bug after posting a feedback here: https://input.mozilla.org/en-AU/dashboard/response/4212430 It also contains some thoughts on presentation for those options. +1 with the addition of a ui to manipulate the stored per-page-settings via something like the stored pw/stored cookies UI -> maybe integrate all three in one place ? BTW. This proposal would also fix Bug 972362, but i am reluctant to just DUPLICATE it here. Maybe a third tracking bug for feature development ? Is somebody reading this knowledgeable about the codebase ? If nobody else steps up, i would be willing to develop a patch, but am really not keen on diving deep into the the codebase all by myself(need a good entry point to the relevant part of the code and an example of how the current implementation stores it's data), when a few pointers would take 90% off the initial development startup time. Then again, for somebody knowledgable this should only be a relatively contained change with much of the infrastructure already in place,therefore the benefit balance between "teach a man to fish" and "just give him the bloody thing" would probably tip in favour of the latter in my specific case. Some additional thoughts: for use case "just this item" + "remember setting", a way to uniquely identify a dom node without an id tag is necessary. Maybe there is something in the internal dom representation that can help, or a diff/hash comparison could be made between current dom serialization/html+css+js/checksum the plugin and it's data and its counterpart for which the "remember" setting was stored. This feature is not central, and an early version could live without it, but it would definitely be nice to activate just this part of the page as long as it hasn't changed.