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