зеркало из https://github.com/mozilla/gecko-dev.git
ca508d989b
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 --HG-- extra : rebase_source : 4709916b4674ada54f8a495fd2d16fcef8c58d20 |
||
|---|---|---|
| .. | ||
| base | ||
| ipc | ||
| test | ||