Only send/update plugins to content when necessary, not all the time
Categories
(Core Graveyard :: Plug-ins, task)
Tracking
(firefox72 fixed)
Tracking | Status | |
---|---|---|
firefox72 | --- | fixed |
People
(Reporter: Gijs, Assigned: Gijs)
References
Details
Attachments
(2 files)
Bug 1592442 noticed that we read plugins.state.flash
a lot under fission.
Digging into it, I remembered that I noticed some of the issue here in bug 1545123 and neglected to file a follow-up bug.
Roughly what happens here is:
- we start a content process and end up in
ContentParent::InitInternal
, which callsnsPluginHost::SendPluginsToContent
nsPluginHost::SendPluginsToContent
loads plugins if necessary (which itself also callsSendPluginsToContent
when finished, btw), then fetches plugin information usingnsPluginHost::GetPlugins()
- it then copies all the plugin information into serializable
PluginTag
instances - then it iterates over all the ContentParents and sends them all the updated list.
Note that the serializable PluginTag
does not include an enabled state - this is read from prefs using Preferences::GetInt()
. Off-hand, I don't see why this pref changing would trigger any updates - the plugin tag instances will just start reporting their new state.
This means that in Fission, for each new per-origin process we create, we serialize the state and send it to all of the content processes. Thankfully, the ones that have already seen this list will know this because the ChromeEpoch
will be the same, and skip doing much - but it'd be better to avoid the IPC traffic altogether. We can do better here by caching the list and splitting out the "update the list for all processes" and "tell this new process of the existing plugin list" responsibilities.
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Comment 2•6 years ago
|
||
Depends on D52845
Comment 4•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/df333402f126
https://hg.mozilla.org/mozilla-central/rev/74ac84aa60fd
Updated•3 years ago
|
Description
•