Aside from making things easier for JS callers, this also makes it harder to
accidentally trigger an early load of the service, which can be expensive
during startup.
This also makes a slight change to nsPluginHost to initially preserve the
previous blocklist state when a plugin is updated, to avoid the risk of the
possible additioanl asynchrony unblocking a plugin that should stay blocked.
MozReview-Commit-ID: 4EvIGJ1Ke0Z
--HG--
rename : toolkit/mozapps/extensions/nsBlocklistService.js => toolkit/mozapps/extensions/Blocklist.jsm
extra : rebase_source : e7047615ea3a728478695c76a0c521b0281f363b
extra : amend_source : b74115abacacd17ae3e8433a534a5bbb541905b0
Since the user can now block Flash and ask the browser to
remember that decision, the histogram that collects user's choices
on this has to be updated with a fourth option.
MozReview-Commit-ID: J4r6nJIiaeQ
--HG--
extra : rebase_source : 782e01f95af000cf21efe1b8790dae9c37ccd717
Migrated to simply use PopupNotifications.jsm. Additionally, this
changes the behavior to always have two buttons and a remember
checkbox. When selecting allow with remember, it will behave like
the always allow option previously, but when selecting block with
remember, it will move that page into a quiet mode with respect
to Flash - i.e., no plugin overlays will show anymore, and instead
you will just see the plugin icon in the URL bar, which you can
continue to interact with as before.
MozReview-Commit-ID: EUFlI7nM09t
--HG--
extra : rebase_source : 4f6fdaa602ea6c398cc646ba98282ee5c154956e
Most of this is fixing functions that in some cases return a value but then
can also run to completion without returning anything. ESLint 2 catches this
where previous versions didn't. Unless there was an obvious other choice I just
made these functions return undefined at the end which is effectively what
already happens.
MozReview-Commit-ID: DEskVIjiKDM
--HG--
extra : rebase_source : 07ba1d14655f5d761624b105ef025ec88323d4d5
extra : histedit_source : 9e5ab54ce1b1a5ee1f0fb143f8d1450522455e3b
showNPAPIPluginCrashedNotification was erroneously calling submitGMPCrashReport, and attempted
to call it with arguments that it definitely didn't have (pluginDumpID, browserDumpID). Now
we call submitCrashReport with a runID, as expected.
--HG--
extra : rebase_source : 78237bbf2ad84c5495c82e465c8653bef2549ba5
This patch does the following:
* Has the gPluginHandler tell content processes when a NPAPI plugin crashes
* Introduces PluginCrashReporter, and renames TabCrashReporter.jsm to ContentCrashReporters.jsm.
* Makes gPluginHandler use PluginCrashReporter to submit plugin crashes.
* If a plugin crash report is submitted, puts all visible instances into the submitted state.
* Makes the plugin crashed notification bar work with run IDs.
* Removes event and message listeners in PluginContent when uninitting.
--HG--
extra : source : 503877a91767a0920fcf0c092c726240d94c8db4
This patch does the following:
* Has the gPluginHandler tell content processes when a NPAPI plugin crashes
* Introduces PluginCrashReporter, and renames TabCrashReporter.jsm to ContentCrashReporters.jsm.
* Makes gPluginHandler use PluginCrashReporter to submit plugin crashes.
* If a plugin crash report is submitted, puts all visible instances into the submitted state.
* Makes the plugin crashed notification bar work with run IDs.
* Removes event and message listeners in PluginContent when uninitting.
--HG--
extra : rebase_source : 04f1f5c755bd4b8e16b7f73cf88955760944b358
Before, we were comparing Principals sent up from PluginContent against the
Principal of the selected browser - this was in order to account for races
(and intermittent oranges) where the browser has moved away from a page before
a CTP message has been received by the parent.
Comparing Principals works beautifully, except in the case of Data URIs, since
Data URIs inherit the Principals of the page they were linked from. That means
that if we're on a page with a link to a Data URI that embeds a plugin, if we
quickly browse to that page and back before a CTP message reaches the parent,
when the CTP message finally arrives, the Principals will match. We solve this
by sending the location as well as the Principal, to do a final comparison if
the Principals do match.
--HG--
extra : rebase_source : 095706306d241a254f62b28527a96a427d7e55c3
extra : histedit_source : 3afe814271166f70afce6a423bbb7809c5a983c7
When the PluginRemoved event is fired when changing locations, it's fired
asynchronously such that the document that the plugin belongs to has already
been unloaded. This was causing the hidden plugin notification to appear in
some cases when users browsed away from documents that had hidden plugins
in them. Now we pass the Principal for the unloading document back to the
parent and do a comparison with the current browser Principal to ensure
that they match before showing the hidden plugin notification.
--HG--
rename : browser/base/content/test/plugins/plugin_small.html => browser/base/content/test/plugins/plugin_small_2.html
extra : rebase_source : e748e3b09de77cc7796b1a78f8e39a23af64049a
We now use message passing and content scripts in order to implement click-to-play. This allows
us to use click-to-play in e10s windows.
--HG--
extra : rebase_source : 6239a4b49e0af89800c5618e4589f8aef03f58d4
We now use message passing and content scripts in order to implement click-to-play. This allows
us to use click-to-play in e10s windows.
--HG--
extra : rebase_source : 719afe669c638ba4883f76f18aee38df6b60b4ad
