gecko-dev/browser/actors/PluginParent.jsm

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

218 строки
6.4 KiB
JavaScript
Исходник Обычный вид История

Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
/* -*- indent-tabs-mode: nil; js-indent-level: 2 -*-
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
"use strict";
var EXPORTED_SYMBOLS = ["PluginParent", "PluginManager"];
const { AppConstants } = ChromeUtils.import(
"resource://gre/modules/AppConstants.jsm"
);
const { Services } = ChromeUtils.import("resource://gre/modules/Services.jsm");
const { XPCOMUtils } = ChromeUtils.import(
"resource://gre/modules/XPCOMUtils.jsm"
);
ChromeUtils.defineModuleGetter(
this,
"CrashSubmit",
"resource://gre/modules/CrashSubmit.jsm"
);
XPCOMUtils.defineLazyGetter(this, "gNavigatorBundle", function() {
const url = "chrome://browser/locale/browser.properties";
return Services.strings.createBundle(url);
});
const PluginManager = {
gmpCrashes: new Map(),
observe(subject, topic, data) {
switch (topic) {
case "gmp-plugin-crash":
this._registerGMPCrash(subject);
break;
}
},
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
_registerGMPCrash(subject) {
let propertyBag = subject;
if (
!(propertyBag instanceof Ci.nsIWritablePropertyBag2) ||
!propertyBag.hasKey("pluginID") ||
!propertyBag.hasKey("pluginDumpID") ||
!propertyBag.hasKey("pluginName")
) {
Cu.reportError("PluginManager can not read plugin information.");
return;
}
let pluginID = propertyBag.getPropertyAsUint32("pluginID");
let pluginDumpID = propertyBag.getPropertyAsAString("pluginDumpID");
let pluginName = propertyBag.getPropertyAsACString("pluginName");
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
if (pluginDumpID) {
this.gmpCrashes.set(pluginID, { pluginDumpID, pluginID, pluginName });
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
}
// Only the parent process gets the gmp-plugin-crash observer
// notification, so we need to inform any content processes that
// the GMP has crashed. This then fires PluginCrashed events in
// all the relevant windows, which will trigger child actors being
// created, which will contact us again, when we'll use the
// gmpCrashes collection to respond.
if (Services.ppmm) {
Services.ppmm.broadcastAsyncMessage("gmp-plugin-crash", {
pluginName,
pluginID,
});
}
},
/**
* Submit a crash report for a crashed plugin.
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
*
* @param pluginCrashID
* An object with a pluginID.
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
* @param keyVals
* An object whose key-value pairs will be merged
* with the ".extra" file submitted with the report.
* The properties of htis object will override properties
* of the same name in the .extra file.
*/
submitCrashReport(pluginCrashID, keyVals = {}) {
let report = this.getCrashReport(pluginCrashID);
if (!report) {
Cu.reportError(
`Could not find plugin dump IDs for ${JSON.stringify(pluginCrashID)}.` +
`It is possible that a report was already submitted.`
);
return;
}
let { pluginDumpID } = report;
CrashSubmit.submit(pluginDumpID, CrashSubmit.SUBMITTED_FROM_CRASH_TAB, {
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
recordSubmission: true,
extraExtraKeyVals: keyVals,
});
this.gmpCrashes.delete(pluginCrashID.pluginID);
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
},
getCrashReport(pluginCrashID) {
return this.gmpCrashes.get(pluginCrashID.pluginID);
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
},
};
class PluginParent extends JSWindowActorParent {
receiveMessage(msg) {
let browser = this.manager.rootFrameLoader.ownerElement;
switch (msg.name) {
case "PluginContent:ShowPluginCrashedNotification":
this.showPluginCrashedNotification(browser, msg.data.pluginCrashID);
break;
default:
Cu.reportError(
"PluginParent did not expect to handle message " + msg.name
);
break;
}
return null;
}
/**
* Shows a plugin-crashed notification bar for a browser that has had a
* GMP plugin crash.
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
*
* @param browser
* The browser to show the notification for.
* @param pluginCrashID
* The unique-per-process identifier for GMP.
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
*/
showPluginCrashedNotification(browser, pluginCrashID) {
// If there's already an existing notification bar, don't do anything.
let notificationBox = browser.getTabBrowser().getNotificationBox(browser);
let notification = notificationBox.getNotificationWithValue(
"plugin-crashed"
);
let report = PluginManager.getCrashReport(pluginCrashID);
if (notification || !report) {
return;
}
// Configure the notification bar
let priority = notificationBox.PRIORITY_WARNING_MEDIUM;
let iconURL = "chrome://global/skin/icons/plugin.svg";
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
let reloadLabel = gNavigatorBundle.GetStringFromName(
"crashedpluginsMessage.reloadButton.label"
);
let reloadKey = gNavigatorBundle.GetStringFromName(
"crashedpluginsMessage.reloadButton.accesskey"
);
let buttons = [
{
label: reloadLabel,
accessKey: reloadKey,
popup: null,
callback() {
browser.reload();
},
},
];
if (AppConstants.MOZ_CRASHREPORTER) {
let submitLabel = gNavigatorBundle.GetStringFromName(
"crashedpluginsMessage.submitButton.label"
);
let submitKey = gNavigatorBundle.GetStringFromName(
"crashedpluginsMessage.submitButton.accesskey"
);
let submitButton = {
label: submitLabel,
accessKey: submitKey,
popup: null,
callback: () => {
PluginManager.submitCrashReport(pluginCrashID);
},
};
buttons.push(submitButton);
}
let messageString = gNavigatorBundle.formatStringFromName(
"crashedpluginsMessage.title",
[report.pluginName]
);
notification = notificationBox.appendNotification(
"plugin-crashed",
{
label: messageString,
image: iconURL,
priority,
},
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
buttons
);
// Add the "learn more" link.
let link = notification.ownerDocument.createXULElement("label", {
is: "text-link",
});
link.setAttribute(
"value",
gNavigatorBundle.GetStringFromName("crashedpluginsMessage.learnMore")
);
let crashurl = Services.urlFormatter.formatURLPref("app.support.baseURL");
crashurl += "plugin-crashed-notificationbar";
link.href = crashurl;
// Append a blank text node to make sure we don't put
// the link right next to the end of the message text.
notification.messageText.appendChild(new Text(" "));
Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley At a high level, this change does the following: - move the pluginchild actor to be a JSWindowActorChild - move the parent handling from browser-plugins into a JSWindowActorParent - move the crash handling from ContentCrashHandlers.jsm to the parent actor, using a `PluginManager` object. It needs to talk to the actors (and vice versa), so this seemed a better fit than spreading actor implementation details to other JSMs. - switch to using plugin IDs to identify plugins cross-process, instead of combinations of names or other properties of the plugin tag. As part of that, ensured plugin IDs are unique between "fake" plugins and the other ones. - drop support for having a notification for more than 1 plugin. We only support Flash, in practice, so there didn't seem to be much point in the added complexity of trying to support more than 1 thing. Some notes: - the previous implementation mixes runIDs (for NPAPI plugin process "runs") and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee these don't conflict, so I've split them out to avoid issues. There's a pluginCrashID object I pass around instead that has either a runID or pluginID. Happy to rename some more for clarity. - the previous implementation used `pluginInfo` and `plugin` for a bunch of different types of variables. I've tried to be consistent, where: * `pluginElement` is a DOM element for a plugin * `activationInfo` is a JS object used to track click to play state for a plugin * `plugin` is a plugintag as returned by the pluginhost service * `pluginCrashID` is an identifier for a crashed plugin (see previous point). - I'm still using broadcastAsyncMessage to tell the content processes about gmp plugin crashes and plugin crash submission updates, because there's no guarantee the actors are instantiated (for gmp plugins) nor can the parent easily find out which actors to talk to (for either gmp or npapi plugins). Open to suggestions there, too. I think our best bet might be moving that to IPDL-based IPC within the GMP code, but that feels like a separate bug. Differential Revision: https://phabricator.services.mozilla.com/D37665 --HG-- rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm extra : moz-landing-system : lando
2019-07-24 01:04:40 +03:00
notification.messageText.appendChild(link);
}
}