Because plugin state in the content now contains blocklist state, and is updated
when the blocklist updates, we don't need to ask the parent if we're checking
blocklist state. All the consumers should now be asking the plugin code directly,
so we can stub out the last API here. We should look at removing the content side
of this service entirely, but that's something for a follow-up bug.
MozReview-Commit-ID: DE8s8RwT42r
This changes the pluginreg.dat format to include the blocklist state.
There is now only the saved blocklist state in a plugin tag instance, rather than
looking it up from in there using the blocklist service, so it was renamed from
mCachedBlocklistState to mBlocklistState. We pass the 'right' state to the plugin
instance when the plugintag is constructed. If we don't have state, we mark it as
unblocked.
mCachedBlocklistStateChanged was never read so it's being removed.
Bug 1439519 adds a 'blocklist-loaded' notification that is fired once the blocklist is loaded.
The plugin host implementation will listen to this in the parent process and update the
blocklist state of all the plugins, and broadcast changes to the child process, just like when
we update the blocklist from the server. We now also avoid re-sending plugin content to the
content processes if the plugin state hasn't changed as a result of the blocklist having been
loaded.
Finally, because new plugins should still get an up-to-date blocklist state, and
telemetry should get up-to-date data about which plugins are and aren't enabled
once we have that data, we ensure that once we've loaded the blocklist async,
we schedule an idle task to parse it and consider it loaded.
All this means that plugin blocklist information could be mistaken between the points where
a new plugin is installed and we first run Firefox with the new plugin, and the point where
we load the blocklist. Given the trade-offs, that size of window (tiny) seems OK, also given
that there's already a much larger window in blocklist updates (which only happen once every 24h).
MozReview-Commit-ID: 1gsojRkUzTw
This adds some more use of Services.jsm, does proper fallback for the app
blocklist if the profile one is unavailable, and avoids parsing the XML
from an updated blocklist twice.
Originally this also switched to using XHR instead of the awful manual
sync-on-mainthread-IO stream parsing, but sync XHR uses event loop
spinning, which breaks random things working the way they should, so
that bit is left until we make this code (hopefully) more async in
nature.
MozReview-Commit-ID: FgXyWl1NNaV
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <
