gecko-dev/browser/actors/PluginChild.jsm

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

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

/* 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 = ["PluginChild"];
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
const { AppConstants } = ChromeUtils.import(
"resource://gre/modules/AppConstants.jsm"
Bug 1514594: Part 3 - Change ChromeUtils.import API. *** Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8 This changes the behavior of ChromeUtils.import() to return an exports object, rather than a module global, in all cases except when `null` is passed as a second argument, and changes the default behavior not to pollute the global scope with the module's exports. Thus, the following code written for the old model: ChromeUtils.import("resource://gre/modules/Services.jsm"); is approximately the same as the following, in the new model: var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm"); Since the two behaviors are mutually incompatible, this patch will land with a scripted rewrite to update all existing callers to use the new model rather than the old. *** Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs This was done using the followng script: https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm *** Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8 Differential Revision: https://phabricator.services.mozilla.com/D16747 *** Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D16748 *** Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D16749 *** Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs *** Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D16750 --HG-- extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895 extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
2019-01-17 21:18:31 +03:00
);
const { BrowserUtils } = ChromeUtils.import(
"resource://gre/modules/BrowserUtils.jsm"
);
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
const { Services } = ChromeUtils.import("resource://gre/modules/Services.jsm");
const { XPCOMUtils } = ChromeUtils.import(
"resource://gre/modules/XPCOMUtils.jsm"
);
XPCOMUtils.defineLazyGetter(this, "gNavigatorBundle", function() {
const url = "chrome://browser/locale/browser.properties";
return Services.strings.createBundle(url);
});
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
XPCOMUtils.defineLazyServiceGetter(
this,
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
"gPluginHost",
"@mozilla.org/plugin/host;1",
"nsIPluginHost"
);
const OVERLAY_DISPLAY = {
HIDDEN: 0, // The overlay will be transparent
BLANK: 1, // The overlay will be just a grey box
TINY: 2, // The overlay with a 16x16 plugin icon
REDUCED: 3, // The overlay with a 32x32 plugin icon
NOTEXT: 4, // The overlay with a 48x48 plugin icon and the close button
FULL: 5, // The full overlay: 48x48 plugin icon, close button and label
};
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
// This gets sent through the content process message manager because the parent
// can't know exactly which child needs to hear about the progress of the
// submission, so we listen "manually" on the CPMM instead of through the actor
// definition.
const kSubmitMsg = "PluginParent:NPAPIPluginCrashReportSubmitted";
class PluginChild extends JSWindowActorChild {
constructor() {
super();
// Cache of plugin crash information sent from the parent
this.pluginCrashData = new Map();
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
Services.cpmm.addMessageListener(kSubmitMsg, this);
}
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
willDestroy() {
Services.cpmm.removeMessageListener(kSubmitMsg, this);
if (this._addedListeners) {
this.contentWindow.removeEventListener("pagehide", this, {
capture: true,
mozSystemGroup: true,
});
this.contentWindow.removeEventListener("pageshow", this, {
capture: true,
mozSystemGroup: true,
});
}
}
receiveMessage(msg) {
switch (msg.name) {
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
case "PluginParent:ActivatePlugins":
this.activatePlugins(msg.data.activationInfo, msg.data.newState);
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
case "PluginParent:NPAPIPluginCrashReportSubmitted":
this.NPAPIPluginCrashReportSubmitted({
runID: msg.data.runID,
state: msg.data.state,
});
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
case "PluginParent:Test:ClearCrashData":
// This message should ONLY ever be sent by automated tests.
if (Services.prefs.getBoolPref("plugins.testmode")) {
this.pluginCrashData.clear();
}
}
}
observe(aSubject, aTopic, aData) {
switch (aTopic) {
case "decoder-doctor-notification":
let data = JSON.parse(aData);
let type = data.type.toLowerCase();
if (
type == "cannot-play" &&
this.haveShownNotification &&
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
aSubject.top.document == this.document &&
data.formats.toLowerCase().includes("application/x-mpegurl", 0)
) {
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
this.contentWindow.pluginRequiresReload = true;
}
}
}
onPageShow(event) {
// Ignore events that aren't from the main document.
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 (!this.contentWindow || event.target != this.document) {
return;
}
// The PluginClickToPlay events are not fired when navigating using the
// BF cache. |persisted| is true when the page is loaded from the
// BF cache, so this code reshows the notification if necessary.
if (event.persisted) {
this.reshowClickToPlayNotification();
}
}
onPageHide(event) {
// Ignore events that aren't from the main document.
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 (!this.contentWindow || event.target != this.document) {
return;
}
this.clearPluginCaches();
this.haveShownNotification = false;
}
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
getPluginUI(pluginElement, anonid) {
Bug 1497940 - Part V, Convert pluginProblem to UA Widget r=smaug This patch creates a pluginProblem UA Widget and constructs it (instead of the XBL pluginProblem binding) when UA Widget is enabled. Tests in browser/base/content/test/plugins/ are duplicated so that we could test both versions. Depends on D11702 Differential Revision: https://phabricator.services.mozilla.com/D11703 --HG-- rename : browser/base/content/test/plugins/.eslintrc.js => browser/base/content/test/plugins/xbl/.eslintrc.js rename : browser/base/content/test/plugins/blockNoPlugins.xml => browser/base/content/test/plugins/xbl/blockNoPlugins.xml rename : browser/base/content/test/plugins/blockPluginHard.xml => browser/base/content/test/plugins/xbl/blockPluginHard.xml rename : browser/base/content/test/plugins/blockPluginInfoURL.xml => browser/base/content/test/plugins/xbl/blockPluginInfoURL.xml rename : browser/base/content/test/plugins/blockPluginVulnerableNoUpdate.xml => browser/base/content/test/plugins/xbl/blockPluginVulnerableNoUpdate.xml rename : browser/base/content/test/plugins/blockPluginVulnerableUpdatable.xml => browser/base/content/test/plugins/xbl/blockPluginVulnerableUpdatable.xml rename : browser/base/content/test/plugins/blocklist_proxy.js => browser/base/content/test/plugins/xbl/blocklist_proxy.js rename : browser/base/content/test/plugins/browser.ini => browser/base/content/test/plugins/xbl/browser.ini rename : browser/base/content/test/plugins/browser_CTP_context_menu.js => browser/base/content/test/plugins/xbl/browser_CTP_context_menu.js rename : browser/base/content/test/plugins/browser_CTP_crashreporting.js => browser/base/content/test/plugins/xbl/browser_CTP_crashreporting.js rename : browser/base/content/test/plugins/browser_CTP_drag_drop.js => browser/base/content/test/plugins/xbl/browser_CTP_drag_drop.js rename : browser/base/content/test/plugins/browser_CTP_favorfallback.js => browser/base/content/test/plugins/xbl/browser_CTP_favorfallback.js rename : browser/base/content/test/plugins/browser_CTP_hide_overlay.js => browser/base/content/test/plugins/xbl/browser_CTP_hide_overlay.js rename : browser/base/content/test/plugins/browser_CTP_iframe.js => browser/base/content/test/plugins/xbl/browser_CTP_iframe.js rename : browser/base/content/test/plugins/browser_CTP_nonplugins.js => browser/base/content/test/plugins/xbl/browser_CTP_nonplugins.js rename : browser/base/content/test/plugins/browser_CTP_outsideScrollArea.js => browser/base/content/test/plugins/xbl/browser_CTP_outsideScrollArea.js rename : browser/base/content/test/plugins/browser_CTP_overlay_styles.js => browser/base/content/test/plugins/xbl/browser_CTP_overlay_styles.js rename : browser/base/content/test/plugins/browser_CTP_resize.js => browser/base/content/test/plugins/xbl/browser_CTP_resize.js rename : browser/base/content/test/plugins/browser_CTP_shouldShowOverlay.js => browser/base/content/test/plugins/xbl/browser_CTP_shouldShowOverlay.js rename : browser/base/content/test/plugins/browser_CTP_zoom.js => browser/base/content/test/plugins/xbl/browser_CTP_zoom.js rename : browser/base/content/test/plugins/browser_blocking.js => browser/base/content/test/plugins/xbl/browser_blocking.js rename : browser/base/content/test/plugins/browser_blocklist_content.js => browser/base/content/test/plugins/xbl/browser_blocklist_content.js rename : browser/base/content/test/plugins/browser_bug743421.js => browser/base/content/test/plugins/xbl/browser_bug743421.js rename : browser/base/content/test/plugins/browser_bug744745.js => browser/base/content/test/plugins/xbl/browser_bug744745.js rename : browser/base/content/test/plugins/browser_bug787619.js => browser/base/content/test/plugins/xbl/browser_bug787619.js rename : browser/base/content/test/plugins/browser_bug797677.js => browser/base/content/test/plugins/xbl/browser_bug797677.js rename : browser/base/content/test/plugins/browser_bug812562.js => browser/base/content/test/plugins/xbl/browser_bug812562.js rename : browser/base/content/test/plugins/browser_bug818118.js => browser/base/content/test/plugins/xbl/browser_bug818118.js rename : browser/base/content/test/plugins/browser_bug820497.js => browser/base/content/test/plugins/xbl/browser_bug820497.js rename : browser/base/content/test/plugins/browser_clearplugindata.html => browser/base/content/test/plugins/xbl/browser_clearplugindata.html rename : browser/base/content/test/plugins/browser_clearplugindata.js => browser/base/content/test/plugins/xbl/browser_clearplugindata.js rename : browser/base/content/test/plugins/browser_clearplugindata_noage.html => browser/base/content/test/plugins/xbl/browser_clearplugindata_noage.html rename : browser/base/content/test/plugins/browser_enable_DRM_prompt.js => browser/base/content/test/plugins/xbl/browser_enable_DRM_prompt.js rename : browser/base/content/test/plugins/browser_globalplugin_crashinfobar.js => browser/base/content/test/plugins/xbl/browser_globalplugin_crashinfobar.js rename : browser/base/content/test/plugins/browser_iterate_hidden_plugins.js => browser/base/content/test/plugins/xbl/browser_iterate_hidden_plugins.js rename : browser/base/content/test/plugins/browser_pluginCrashCommentAndURL.js => browser/base/content/test/plugins/xbl/browser_pluginCrashCommentAndURL.js rename : browser/base/content/test/plugins/browser_pluginCrashReportNonDeterminism.js => browser/base/content/test/plugins/xbl/browser_pluginCrashReportNonDeterminism.js rename : browser/base/content/test/plugins/browser_plugin_reloading.js => browser/base/content/test/plugins/xbl/browser_plugin_reloading.js rename : browser/base/content/test/plugins/browser_pluginnotification.js => browser/base/content/test/plugins/xbl/browser_pluginnotification.js rename : browser/base/content/test/plugins/browser_private_browsing_eme_persistent_state.js => browser/base/content/test/plugins/xbl/browser_private_browsing_eme_persistent_state.js rename : browser/base/content/test/plugins/browser_private_clicktoplay.js => browser/base/content/test/plugins/xbl/browser_private_clicktoplay.js rename : browser/base/content/test/plugins/browser_subframe_access_hidden_plugins.js => browser/base/content/test/plugins/xbl/browser_subframe_access_hidden_plugins.js rename : browser/base/content/test/plugins/empty_file.html => browser/base/content/test/plugins/xbl/empty_file.html rename : browser/base/content/test/plugins/plugin_add_dynamically.html => browser/base/content/test/plugins/xbl/plugin_add_dynamically.html rename : browser/base/content/test/plugins/plugin_alternate_content.html => browser/base/content/test/plugins/xbl/plugin_alternate_content.html rename : browser/base/content/test/plugins/plugin_big.html => browser/base/content/test/plugins/xbl/plugin_big.html rename : browser/base/content/test/plugins/plugin_both.html => browser/base/content/test/plugins/xbl/plugin_both.html rename : browser/base/content/test/plugins/plugin_both2.html => browser/base/content/test/plugins/xbl/plugin_both2.html rename : browser/base/content/test/plugins/plugin_bug744745.html => browser/base/content/test/plugins/xbl/plugin_bug744745.html rename : browser/base/content/test/plugins/plugin_bug749455.html => browser/base/content/test/plugins/xbl/plugin_bug749455.html rename : browser/base/content/test/plugins/plugin_bug787619.html => browser/base/content/test/plugins/xbl/plugin_bug787619.html rename : browser/base/content/test/plugins/plugin_bug797677.html => browser/base/content/test/plugins/xbl/plugin_bug797677.html rename : browser/base/content/test/plugins/plugin_bug820497.html => browser/base/content/test/plugins/xbl/plugin_bug820497.html rename : browser/base/content/test/plugins/plugin_clickToPlayAllow.html => browser/base/content/test/plugins/xbl/plugin_clickToPlayAllow.html rename : browser/base/content/test/plugins/plugin_clickToPlayDeny.html => browser/base/content/test/plugins/xbl/plugin_clickToPlayDeny.html rename : browser/base/content/test/plugins/plugin_crashCommentAndURL.html => browser/base/content/test/plugins/xbl/plugin_crashCommentAndURL.html rename : browser/base/content/test/plugins/plugin_favorfallback.html => browser/base/content/test/plugins/xbl/plugin_favorfallback.html rename : browser/base/content/test/plugins/plugin_hidden_to_visible.html => browser/base/content/test/plugins/xbl/plugin_hidden_to_visible.html rename : browser/base/content/test/plugins/plugin_iframe.html => browser/base/content/test/plugins/xbl/plugin_iframe.html rename : browser/base/content/test/plugins/plugin_outsideScrollArea.html => browser/base/content/test/plugins/xbl/plugin_outsideScrollArea.html rename : browser/base/content/test/plugins/plugin_overlay_styles.html => browser/base/content/test/plugins/xbl/plugin_overlay_styles.html rename : browser/base/content/test/plugins/plugin_shouldShowOverlay.html => browser/base/content/test/plugins/xbl/plugin_shouldShowOverlay.html rename : browser/base/content/test/plugins/plugin_simple_blank.swf => browser/base/content/test/plugins/xbl/plugin_simple_blank.swf rename : browser/base/content/test/plugins/plugin_small.html => browser/base/content/test/plugins/xbl/plugin_small.html rename : browser/base/content/test/plugins/plugin_small_2.html => browser/base/content/test/plugins/xbl/plugin_small_2.html rename : browser/base/content/test/plugins/plugin_syncRemoved.html => browser/base/content/test/plugins/xbl/plugin_syncRemoved.html rename : browser/base/content/test/plugins/plugin_test.html => browser/base/content/test/plugins/xbl/plugin_test.html rename : browser/base/content/test/plugins/plugin_test2.html => browser/base/content/test/plugins/xbl/plugin_test2.html rename : browser/base/content/test/plugins/plugin_test3.html => browser/base/content/test/plugins/xbl/plugin_test3.html rename : browser/base/content/test/plugins/plugin_two_types.html => browser/base/content/test/plugins/xbl/plugin_two_types.html rename : browser/base/content/test/plugins/plugin_unknown.html => browser/base/content/test/plugins/xbl/plugin_unknown.html rename : browser/base/content/test/plugins/plugin_zoom.html => browser/base/content/test/plugins/xbl/plugin_zoom.html rename : toolkit/pluginproblem/content/pluginProblem.xml => toolkit/content/widgets/pluginProblem.js extra : moz-landing-system : lando
2018-11-22 08:49:54 +03:00
if (
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
pluginElement.openOrClosedShadowRoot &&
pluginElement.openOrClosedShadowRoot.isUAWidget()
Bug 1497940 - Part V, Convert pluginProblem to UA Widget r=smaug This patch creates a pluginProblem UA Widget and constructs it (instead of the XBL pluginProblem binding) when UA Widget is enabled. Tests in browser/base/content/test/plugins/ are duplicated so that we could test both versions. Depends on D11702 Differential Revision: https://phabricator.services.mozilla.com/D11703 --HG-- rename : browser/base/content/test/plugins/.eslintrc.js => browser/base/content/test/plugins/xbl/.eslintrc.js rename : browser/base/content/test/plugins/blockNoPlugins.xml => browser/base/content/test/plugins/xbl/blockNoPlugins.xml rename : browser/base/content/test/plugins/blockPluginHard.xml => browser/base/content/test/plugins/xbl/blockPluginHard.xml rename : browser/base/content/test/plugins/blockPluginInfoURL.xml => browser/base/content/test/plugins/xbl/blockPluginInfoURL.xml rename : browser/base/content/test/plugins/blockPluginVulnerableNoUpdate.xml => browser/base/content/test/plugins/xbl/blockPluginVulnerableNoUpdate.xml rename : browser/base/content/test/plugins/blockPluginVulnerableUpdatable.xml => browser/base/content/test/plugins/xbl/blockPluginVulnerableUpdatable.xml rename : browser/base/content/test/plugins/blocklist_proxy.js => browser/base/content/test/plugins/xbl/blocklist_proxy.js rename : browser/base/content/test/plugins/browser.ini => browser/base/content/test/plugins/xbl/browser.ini rename : browser/base/content/test/plugins/browser_CTP_context_menu.js => browser/base/content/test/plugins/xbl/browser_CTP_context_menu.js rename : browser/base/content/test/plugins/browser_CTP_crashreporting.js => browser/base/content/test/plugins/xbl/browser_CTP_crashreporting.js rename : browser/base/content/test/plugins/browser_CTP_drag_drop.js => browser/base/content/test/plugins/xbl/browser_CTP_drag_drop.js rename : browser/base/content/test/plugins/browser_CTP_favorfallback.js => browser/base/content/test/plugins/xbl/browser_CTP_favorfallback.js rename : browser/base/content/test/plugins/browser_CTP_hide_overlay.js => browser/base/content/test/plugins/xbl/browser_CTP_hide_overlay.js rename : browser/base/content/test/plugins/browser_CTP_iframe.js => browser/base/content/test/plugins/xbl/browser_CTP_iframe.js rename : browser/base/content/test/plugins/browser_CTP_nonplugins.js => browser/base/content/test/plugins/xbl/browser_CTP_nonplugins.js rename : browser/base/content/test/plugins/browser_CTP_outsideScrollArea.js => browser/base/content/test/plugins/xbl/browser_CTP_outsideScrollArea.js rename : browser/base/content/test/plugins/browser_CTP_overlay_styles.js => browser/base/content/test/plugins/xbl/browser_CTP_overlay_styles.js rename : browser/base/content/test/plugins/browser_CTP_resize.js => browser/base/content/test/plugins/xbl/browser_CTP_resize.js rename : browser/base/content/test/plugins/browser_CTP_shouldShowOverlay.js => browser/base/content/test/plugins/xbl/browser_CTP_shouldShowOverlay.js rename : browser/base/content/test/plugins/browser_CTP_zoom.js => browser/base/content/test/plugins/xbl/browser_CTP_zoom.js rename : browser/base/content/test/plugins/browser_blocking.js => browser/base/content/test/plugins/xbl/browser_blocking.js rename : browser/base/content/test/plugins/browser_blocklist_content.js => browser/base/content/test/plugins/xbl/browser_blocklist_content.js rename : browser/base/content/test/plugins/browser_bug743421.js => browser/base/content/test/plugins/xbl/browser_bug743421.js rename : browser/base/content/test/plugins/browser_bug744745.js => browser/base/content/test/plugins/xbl/browser_bug744745.js rename : browser/base/content/test/plugins/browser_bug787619.js => browser/base/content/test/plugins/xbl/browser_bug787619.js rename : browser/base/content/test/plugins/browser_bug797677.js => browser/base/content/test/plugins/xbl/browser_bug797677.js rename : browser/base/content/test/plugins/browser_bug812562.js => browser/base/content/test/plugins/xbl/browser_bug812562.js rename : browser/base/content/test/plugins/browser_bug818118.js => browser/base/content/test/plugins/xbl/browser_bug818118.js rename : browser/base/content/test/plugins/browser_bug820497.js => browser/base/content/test/plugins/xbl/browser_bug820497.js rename : browser/base/content/test/plugins/browser_clearplugindata.html => browser/base/content/test/plugins/xbl/browser_clearplugindata.html rename : browser/base/content/test/plugins/browser_clearplugindata.js => browser/base/content/test/plugins/xbl/browser_clearplugindata.js rename : browser/base/content/test/plugins/browser_clearplugindata_noage.html => browser/base/content/test/plugins/xbl/browser_clearplugindata_noage.html rename : browser/base/content/test/plugins/browser_enable_DRM_prompt.js => browser/base/content/test/plugins/xbl/browser_enable_DRM_prompt.js rename : browser/base/content/test/plugins/browser_globalplugin_crashinfobar.js => browser/base/content/test/plugins/xbl/browser_globalplugin_crashinfobar.js rename : browser/base/content/test/plugins/browser_iterate_hidden_plugins.js => browser/base/content/test/plugins/xbl/browser_iterate_hidden_plugins.js rename : browser/base/content/test/plugins/browser_pluginCrashCommentAndURL.js => browser/base/content/test/plugins/xbl/browser_pluginCrashCommentAndURL.js rename : browser/base/content/test/plugins/browser_pluginCrashReportNonDeterminism.js => browser/base/content/test/plugins/xbl/browser_pluginCrashReportNonDeterminism.js rename : browser/base/content/test/plugins/browser_plugin_reloading.js => browser/base/content/test/plugins/xbl/browser_plugin_reloading.js rename : browser/base/content/test/plugins/browser_pluginnotification.js => browser/base/content/test/plugins/xbl/browser_pluginnotification.js rename : browser/base/content/test/plugins/browser_private_browsing_eme_persistent_state.js => browser/base/content/test/plugins/xbl/browser_private_browsing_eme_persistent_state.js rename : browser/base/content/test/plugins/browser_private_clicktoplay.js => browser/base/content/test/plugins/xbl/browser_private_clicktoplay.js rename : browser/base/content/test/plugins/browser_subframe_access_hidden_plugins.js => browser/base/content/test/plugins/xbl/browser_subframe_access_hidden_plugins.js rename : browser/base/content/test/plugins/empty_file.html => browser/base/content/test/plugins/xbl/empty_file.html rename : browser/base/content/test/plugins/plugin_add_dynamically.html => browser/base/content/test/plugins/xbl/plugin_add_dynamically.html rename : browser/base/content/test/plugins/plugin_alternate_content.html => browser/base/content/test/plugins/xbl/plugin_alternate_content.html rename : browser/base/content/test/plugins/plugin_big.html => browser/base/content/test/plugins/xbl/plugin_big.html rename : browser/base/content/test/plugins/plugin_both.html => browser/base/content/test/plugins/xbl/plugin_both.html rename : browser/base/content/test/plugins/plugin_both2.html => browser/base/content/test/plugins/xbl/plugin_both2.html rename : browser/base/content/test/plugins/plugin_bug744745.html => browser/base/content/test/plugins/xbl/plugin_bug744745.html rename : browser/base/content/test/plugins/plugin_bug749455.html => browser/base/content/test/plugins/xbl/plugin_bug749455.html rename : browser/base/content/test/plugins/plugin_bug787619.html => browser/base/content/test/plugins/xbl/plugin_bug787619.html rename : browser/base/content/test/plugins/plugin_bug797677.html => browser/base/content/test/plugins/xbl/plugin_bug797677.html rename : browser/base/content/test/plugins/plugin_bug820497.html => browser/base/content/test/plugins/xbl/plugin_bug820497.html rename : browser/base/content/test/plugins/plugin_clickToPlayAllow.html => browser/base/content/test/plugins/xbl/plugin_clickToPlayAllow.html rename : browser/base/content/test/plugins/plugin_clickToPlayDeny.html => browser/base/content/test/plugins/xbl/plugin_clickToPlayDeny.html rename : browser/base/content/test/plugins/plugin_crashCommentAndURL.html => browser/base/content/test/plugins/xbl/plugin_crashCommentAndURL.html rename : browser/base/content/test/plugins/plugin_favorfallback.html => browser/base/content/test/plugins/xbl/plugin_favorfallback.html rename : browser/base/content/test/plugins/plugin_hidden_to_visible.html => browser/base/content/test/plugins/xbl/plugin_hidden_to_visible.html rename : browser/base/content/test/plugins/plugin_iframe.html => browser/base/content/test/plugins/xbl/plugin_iframe.html rename : browser/base/content/test/plugins/plugin_outsideScrollArea.html => browser/base/content/test/plugins/xbl/plugin_outsideScrollArea.html rename : browser/base/content/test/plugins/plugin_overlay_styles.html => browser/base/content/test/plugins/xbl/plugin_overlay_styles.html rename : browser/base/content/test/plugins/plugin_shouldShowOverlay.html => browser/base/content/test/plugins/xbl/plugin_shouldShowOverlay.html rename : browser/base/content/test/plugins/plugin_simple_blank.swf => browser/base/content/test/plugins/xbl/plugin_simple_blank.swf rename : browser/base/content/test/plugins/plugin_small.html => browser/base/content/test/plugins/xbl/plugin_small.html rename : browser/base/content/test/plugins/plugin_small_2.html => browser/base/content/test/plugins/xbl/plugin_small_2.html rename : browser/base/content/test/plugins/plugin_syncRemoved.html => browser/base/content/test/plugins/xbl/plugin_syncRemoved.html rename : browser/base/content/test/plugins/plugin_test.html => browser/base/content/test/plugins/xbl/plugin_test.html rename : browser/base/content/test/plugins/plugin_test2.html => browser/base/content/test/plugins/xbl/plugin_test2.html rename : browser/base/content/test/plugins/plugin_test3.html => browser/base/content/test/plugins/xbl/plugin_test3.html rename : browser/base/content/test/plugins/plugin_two_types.html => browser/base/content/test/plugins/xbl/plugin_two_types.html rename : browser/base/content/test/plugins/plugin_unknown.html => browser/base/content/test/plugins/xbl/plugin_unknown.html rename : browser/base/content/test/plugins/plugin_zoom.html => browser/base/content/test/plugins/xbl/plugin_zoom.html rename : toolkit/pluginproblem/content/pluginProblem.xml => toolkit/content/widgets/pluginProblem.js extra : moz-landing-system : lando
2018-11-22 08:49:54 +03:00
) {
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
return pluginElement.openOrClosedShadowRoot.getElementById(anonid);
Bug 1497940 - Part V, Convert pluginProblem to UA Widget r=smaug This patch creates a pluginProblem UA Widget and constructs it (instead of the XBL pluginProblem binding) when UA Widget is enabled. Tests in browser/base/content/test/plugins/ are duplicated so that we could test both versions. Depends on D11702 Differential Revision: https://phabricator.services.mozilla.com/D11703 --HG-- rename : browser/base/content/test/plugins/.eslintrc.js => browser/base/content/test/plugins/xbl/.eslintrc.js rename : browser/base/content/test/plugins/blockNoPlugins.xml => browser/base/content/test/plugins/xbl/blockNoPlugins.xml rename : browser/base/content/test/plugins/blockPluginHard.xml => browser/base/content/test/plugins/xbl/blockPluginHard.xml rename : browser/base/content/test/plugins/blockPluginInfoURL.xml => browser/base/content/test/plugins/xbl/blockPluginInfoURL.xml rename : browser/base/content/test/plugins/blockPluginVulnerableNoUpdate.xml => browser/base/content/test/plugins/xbl/blockPluginVulnerableNoUpdate.xml rename : browser/base/content/test/plugins/blockPluginVulnerableUpdatable.xml => browser/base/content/test/plugins/xbl/blockPluginVulnerableUpdatable.xml rename : browser/base/content/test/plugins/blocklist_proxy.js => browser/base/content/test/plugins/xbl/blocklist_proxy.js rename : browser/base/content/test/plugins/browser.ini => browser/base/content/test/plugins/xbl/browser.ini rename : browser/base/content/test/plugins/browser_CTP_context_menu.js => browser/base/content/test/plugins/xbl/browser_CTP_context_menu.js rename : browser/base/content/test/plugins/browser_CTP_crashreporting.js => browser/base/content/test/plugins/xbl/browser_CTP_crashreporting.js rename : browser/base/content/test/plugins/browser_CTP_drag_drop.js => browser/base/content/test/plugins/xbl/browser_CTP_drag_drop.js rename : browser/base/content/test/plugins/browser_CTP_favorfallback.js => browser/base/content/test/plugins/xbl/browser_CTP_favorfallback.js rename : browser/base/content/test/plugins/browser_CTP_hide_overlay.js => browser/base/content/test/plugins/xbl/browser_CTP_hide_overlay.js rename : browser/base/content/test/plugins/browser_CTP_iframe.js => browser/base/content/test/plugins/xbl/browser_CTP_iframe.js rename : browser/base/content/test/plugins/browser_CTP_nonplugins.js => browser/base/content/test/plugins/xbl/browser_CTP_nonplugins.js rename : browser/base/content/test/plugins/browser_CTP_outsideScrollArea.js => browser/base/content/test/plugins/xbl/browser_CTP_outsideScrollArea.js rename : browser/base/content/test/plugins/browser_CTP_overlay_styles.js => browser/base/content/test/plugins/xbl/browser_CTP_overlay_styles.js rename : browser/base/content/test/plugins/browser_CTP_resize.js => browser/base/content/test/plugins/xbl/browser_CTP_resize.js rename : browser/base/content/test/plugins/browser_CTP_shouldShowOverlay.js => browser/base/content/test/plugins/xbl/browser_CTP_shouldShowOverlay.js rename : browser/base/content/test/plugins/browser_CTP_zoom.js => browser/base/content/test/plugins/xbl/browser_CTP_zoom.js rename : browser/base/content/test/plugins/browser_blocking.js => browser/base/content/test/plugins/xbl/browser_blocking.js rename : browser/base/content/test/plugins/browser_blocklist_content.js => browser/base/content/test/plugins/xbl/browser_blocklist_content.js rename : browser/base/content/test/plugins/browser_bug743421.js => browser/base/content/test/plugins/xbl/browser_bug743421.js rename : browser/base/content/test/plugins/browser_bug744745.js => browser/base/content/test/plugins/xbl/browser_bug744745.js rename : browser/base/content/test/plugins/browser_bug787619.js => browser/base/content/test/plugins/xbl/browser_bug787619.js rename : browser/base/content/test/plugins/browser_bug797677.js => browser/base/content/test/plugins/xbl/browser_bug797677.js rename : browser/base/content/test/plugins/browser_bug812562.js => browser/base/content/test/plugins/xbl/browser_bug812562.js rename : browser/base/content/test/plugins/browser_bug818118.js => browser/base/content/test/plugins/xbl/browser_bug818118.js rename : browser/base/content/test/plugins/browser_bug820497.js => browser/base/content/test/plugins/xbl/browser_bug820497.js rename : browser/base/content/test/plugins/browser_clearplugindata.html => browser/base/content/test/plugins/xbl/browser_clearplugindata.html rename : browser/base/content/test/plugins/browser_clearplugindata.js => browser/base/content/test/plugins/xbl/browser_clearplugindata.js rename : browser/base/content/test/plugins/browser_clearplugindata_noage.html => browser/base/content/test/plugins/xbl/browser_clearplugindata_noage.html rename : browser/base/content/test/plugins/browser_enable_DRM_prompt.js => browser/base/content/test/plugins/xbl/browser_enable_DRM_prompt.js rename : browser/base/content/test/plugins/browser_globalplugin_crashinfobar.js => browser/base/content/test/plugins/xbl/browser_globalplugin_crashinfobar.js rename : browser/base/content/test/plugins/browser_iterate_hidden_plugins.js => browser/base/content/test/plugins/xbl/browser_iterate_hidden_plugins.js rename : browser/base/content/test/plugins/browser_pluginCrashCommentAndURL.js => browser/base/content/test/plugins/xbl/browser_pluginCrashCommentAndURL.js rename : browser/base/content/test/plugins/browser_pluginCrashReportNonDeterminism.js => browser/base/content/test/plugins/xbl/browser_pluginCrashReportNonDeterminism.js rename : browser/base/content/test/plugins/browser_plugin_reloading.js => browser/base/content/test/plugins/xbl/browser_plugin_reloading.js rename : browser/base/content/test/plugins/browser_pluginnotification.js => browser/base/content/test/plugins/xbl/browser_pluginnotification.js rename : browser/base/content/test/plugins/browser_private_browsing_eme_persistent_state.js => browser/base/content/test/plugins/xbl/browser_private_browsing_eme_persistent_state.js rename : browser/base/content/test/plugins/browser_private_clicktoplay.js => browser/base/content/test/plugins/xbl/browser_private_clicktoplay.js rename : browser/base/content/test/plugins/browser_subframe_access_hidden_plugins.js => browser/base/content/test/plugins/xbl/browser_subframe_access_hidden_plugins.js rename : browser/base/content/test/plugins/empty_file.html => browser/base/content/test/plugins/xbl/empty_file.html rename : browser/base/content/test/plugins/plugin_add_dynamically.html => browser/base/content/test/plugins/xbl/plugin_add_dynamically.html rename : browser/base/content/test/plugins/plugin_alternate_content.html => browser/base/content/test/plugins/xbl/plugin_alternate_content.html rename : browser/base/content/test/plugins/plugin_big.html => browser/base/content/test/plugins/xbl/plugin_big.html rename : browser/base/content/test/plugins/plugin_both.html => browser/base/content/test/plugins/xbl/plugin_both.html rename : browser/base/content/test/plugins/plugin_both2.html => browser/base/content/test/plugins/xbl/plugin_both2.html rename : browser/base/content/test/plugins/plugin_bug744745.html => browser/base/content/test/plugins/xbl/plugin_bug744745.html rename : browser/base/content/test/plugins/plugin_bug749455.html => browser/base/content/test/plugins/xbl/plugin_bug749455.html rename : browser/base/content/test/plugins/plugin_bug787619.html => browser/base/content/test/plugins/xbl/plugin_bug787619.html rename : browser/base/content/test/plugins/plugin_bug797677.html => browser/base/content/test/plugins/xbl/plugin_bug797677.html rename : browser/base/content/test/plugins/plugin_bug820497.html => browser/base/content/test/plugins/xbl/plugin_bug820497.html rename : browser/base/content/test/plugins/plugin_clickToPlayAllow.html => browser/base/content/test/plugins/xbl/plugin_clickToPlayAllow.html rename : browser/base/content/test/plugins/plugin_clickToPlayDeny.html => browser/base/content/test/plugins/xbl/plugin_clickToPlayDeny.html rename : browser/base/content/test/plugins/plugin_crashCommentAndURL.html => browser/base/content/test/plugins/xbl/plugin_crashCommentAndURL.html rename : browser/base/content/test/plugins/plugin_favorfallback.html => browser/base/content/test/plugins/xbl/plugin_favorfallback.html rename : browser/base/content/test/plugins/plugin_hidden_to_visible.html => browser/base/content/test/plugins/xbl/plugin_hidden_to_visible.html rename : browser/base/content/test/plugins/plugin_iframe.html => browser/base/content/test/plugins/xbl/plugin_iframe.html rename : browser/base/content/test/plugins/plugin_outsideScrollArea.html => browser/base/content/test/plugins/xbl/plugin_outsideScrollArea.html rename : browser/base/content/test/plugins/plugin_overlay_styles.html => browser/base/content/test/plugins/xbl/plugin_overlay_styles.html rename : browser/base/content/test/plugins/plugin_shouldShowOverlay.html => browser/base/content/test/plugins/xbl/plugin_shouldShowOverlay.html rename : browser/base/content/test/plugins/plugin_simple_blank.swf => browser/base/content/test/plugins/xbl/plugin_simple_blank.swf rename : browser/base/content/test/plugins/plugin_small.html => browser/base/content/test/plugins/xbl/plugin_small.html rename : browser/base/content/test/plugins/plugin_small_2.html => browser/base/content/test/plugins/xbl/plugin_small_2.html rename : browser/base/content/test/plugins/plugin_syncRemoved.html => browser/base/content/test/plugins/xbl/plugin_syncRemoved.html rename : browser/base/content/test/plugins/plugin_test.html => browser/base/content/test/plugins/xbl/plugin_test.html rename : browser/base/content/test/plugins/plugin_test2.html => browser/base/content/test/plugins/xbl/plugin_test2.html rename : browser/base/content/test/plugins/plugin_test3.html => browser/base/content/test/plugins/xbl/plugin_test3.html rename : browser/base/content/test/plugins/plugin_two_types.html => browser/base/content/test/plugins/xbl/plugin_two_types.html rename : browser/base/content/test/plugins/plugin_unknown.html => browser/base/content/test/plugins/xbl/plugin_unknown.html rename : browser/base/content/test/plugins/plugin_zoom.html => browser/base/content/test/plugins/xbl/plugin_zoom.html rename : toolkit/pluginproblem/content/pluginProblem.xml => toolkit/content/widgets/pluginProblem.js extra : moz-landing-system : lando
2018-11-22 08:49:54 +03:00
}
return null;
}
_getPluginInfo(pluginElement) {
if (this.isKnownPlugin(pluginElement)) {
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 pluginTag = gPluginHost.getPluginTagForType(pluginElement.actualType);
let pluginName = BrowserUtils.makeNicePluginName(pluginTag.name);
let fallbackType = pluginElement.defaultFallbackType;
let permissionString = gPluginHost.getPermissionStringForType(
pluginElement.actualType
);
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
return { pluginTag, pluginName, fallbackType, permissionString };
}
return {
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
fallbackType: null,
permissionString: null,
pluginName: gNavigatorBundle.GetStringFromName(
"pluginInfo.unknownPlugin"
),
pluginTag: null,
};
}
/**
* _getPluginInfoForTag is called when iterating the plugins for a document,
* and what we get from nsIDOMWindowUtils is an nsIPluginTag, and not an
* nsIObjectLoadingContent. This only should happen if the plugin is
* click-to-play (see bug 1186948).
*/
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
_getPluginInfoForTag(pluginTag) {
// Since we should only have entered _getPluginInfoForTag when
// examining a click-to-play plugin, we can safely hard-code
// this fallback type, since we don't actually have an
// nsIObjectLoadingContent to check.
let fallbackType = Ci.nsIObjectLoadingContent.PLUGIN_CLICK_TO_PLAY;
if (pluginTag) {
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 pluginName = BrowserUtils.makeNicePluginName(pluginTag.name);
let permissionString = gPluginHost.getPermissionStringForTag(pluginTag);
return { pluginTag, pluginName, permissionString, fallbackType };
}
return {
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
fallbackType,
permissionString: null,
pluginName: gNavigatorBundle.GetStringFromName(
"pluginInfo.unknownPlugin"
),
pluginTag: null,
};
}
/**
* Update the visibility of the plugin overlay.
*/
setVisibility(plugin, overlay, overlayDisplayState) {
overlay.classList.toggle(
"visible",
overlayDisplayState != OVERLAY_DISPLAY.HIDDEN
);
if (overlayDisplayState != OVERLAY_DISPLAY.HIDDEN) {
overlay.removeAttribute("dismissed");
}
}
/**
* Adjust the style in which the overlay will be displayed. It might be adjusted
* based on its size, or if there's some other element covering all corners of
* the overlay.
*
* This function will handle adjusting the style of the overlay, but will
* not handle hiding it. That is done by setVisibility with the return value
* from this function.
*
* @param {Element} plugin The plug-in element
* @param {Element} overlay The overlay element inside the UA Shadow DOM of
* the plug-in element
* @param {boolean} flushLayout Allow flush layout during computation and
* adjustment.
* @returns A value from OVERLAY_DISPLAY.
*/
computeAndAdjustOverlayDisplay(plugin, overlay, flushLayout) {
let fallbackType = plugin.pluginFallbackType;
if (plugin.pluginFallbackTypeOverride !== undefined) {
fallbackType = plugin.pluginFallbackTypeOverride;
}
if (fallbackType == Ci.nsIObjectLoadingContent.PLUGIN_CLICK_TO_PLAY_QUIET) {
return OVERLAY_DISPLAY.HIDDEN;
}
// If the overlay size is 0, we haven't done layout yet. Presume that
// plugins are visible until we know otherwise.
if (flushLayout && overlay.scrollWidth == 0) {
return OVERLAY_DISPLAY.FULL;
}
let overlayDisplay = OVERLAY_DISPLAY.FULL;
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 cwu = plugin.ownerGlobal.windowUtils;
// Is the <object>'s size too small to hold what we want to show?
let pluginRect = flushLayout
? plugin.getBoundingClientRect()
: cwu.getBoundsWithoutFlushing(plugin);
let pluginWidth = Math.ceil(pluginRect.width);
let pluginHeight = Math.ceil(pluginRect.height);
let layoutNeedsFlush =
!flushLayout &&
cwu.needsFlush(cwu.FLUSH_STYLE) &&
cwu.needsFlush(cwu.FLUSH_LAYOUT);
// We must set the attributes while here inside this function in order
// for a possible re-style to occur, which will make the scrollWidth/Height
// checks below correct. Otherwise, we would be requesting e.g. a TINY
// overlay here, but the default styling would be used, and that would make
// it overflow, causing it to change to BLANK instead of remaining as TINY.
if (layoutNeedsFlush) {
// Set the content to be oversized when we the overlay size is 0,
// so that we could receive an overflow event afterwards when there is
// a layout.
overlayDisplay = OVERLAY_DISPLAY.FULL;
overlay.setAttribute("sizing", "oversized");
overlay.removeAttribute("notext");
} else if (pluginWidth <= 32 || pluginHeight <= 32) {
overlay.setAttribute("sizing", "blank");
overlayDisplay = OVERLAY_DISPLAY.BLANK;
} else if (pluginWidth <= 80 || pluginHeight <= 60) {
overlayDisplay = OVERLAY_DISPLAY.TINY;
overlay.setAttribute("sizing", "tiny");
overlay.setAttribute("notext", "notext");
} else if (pluginWidth <= 120 || pluginHeight <= 80) {
overlayDisplay = OVERLAY_DISPLAY.REDUCED;
overlay.setAttribute("sizing", "reduced");
overlay.setAttribute("notext", "notext");
} else if (pluginWidth <= 240 || pluginHeight <= 160) {
overlayDisplay = OVERLAY_DISPLAY.NOTEXT;
overlay.removeAttribute("sizing");
overlay.setAttribute("notext", "notext");
} else {
overlayDisplay = OVERLAY_DISPLAY.FULL;
overlay.removeAttribute("sizing");
overlay.removeAttribute("notext");
}
// The hit test below only works with correct layout information,
// don't do it if layout needs flush.
// We also don't want to access scrollWidth/scrollHeight if
// the layout needs flush.
if (layoutNeedsFlush) {
return overlayDisplay;
}
// XXX bug 446693. The text-shadow on the submitted-report text at
// the bottom causes scrollHeight to be larger than it should be.
let overflows =
overlay.scrollWidth > pluginWidth ||
overlay.scrollHeight - 5 > pluginHeight;
if (overflows) {
overlay.setAttribute("sizing", "blank");
return OVERLAY_DISPLAY.BLANK;
}
// Is the plugin covered up by other content so that it is not clickable?
// Floating point can confuse .elementFromPoint, so inset just a bit
let left = pluginRect.left + 2;
let right = pluginRect.right - 2;
let top = pluginRect.top + 2;
let bottom = pluginRect.bottom - 2;
let centerX = left + (right - left) / 2;
let centerY = top + (bottom - top) / 2;
let points = [
[left, top],
[left, bottom],
[right, top],
[right, bottom],
[centerX, centerY],
];
for (let [x, y] of points) {
if (x < 0 || y < 0) {
continue;
}
let el = cwu.elementFromPoint(x, y, true, true);
if (el === plugin) {
return overlayDisplay;
}
}
overlay.setAttribute("sizing", "blank");
return OVERLAY_DISPLAY.BLANK;
}
addLinkClickCallback(linkNode, callbackName /* callbackArgs...*/) {
// XXX just doing (callback)(arg) was giving a same-origin error. bug?
let self = this;
let callbackArgs = Array.prototype.slice.call(arguments).slice(2);
linkNode.addEventListener(
"click",
function(evt) {
if (!evt.isTrusted) {
return;
}
evt.preventDefault();
if (!callbackArgs.length) {
callbackArgs = [evt];
}
self[callbackName].apply(self, callbackArgs);
},
true
);
linkNode.addEventListener(
"keydown",
function(evt) {
if (!evt.isTrusted) {
return;
}
if (evt.keyCode == evt.DOM_VK_RETURN) {
evt.preventDefault();
if (!callbackArgs.length) {
callbackArgs = [evt];
}
evt.preventDefault();
self[callbackName].apply(self, callbackArgs);
}
},
true
);
}
// Helper to get the binding handler type from a plugin object
_getBindingType(plugin) {
if (!(plugin instanceof Ci.nsIObjectLoadingContent)) {
return null;
}
switch (plugin.pluginFallbackType) {
case Ci.nsIObjectLoadingContent.PLUGIN_UNSUPPORTED:
return "PluginNotFound";
case Ci.nsIObjectLoadingContent.PLUGIN_DISABLED:
return "PluginDisabled";
case Ci.nsIObjectLoadingContent.PLUGIN_BLOCKLISTED:
return "PluginBlocklisted";
case Ci.nsIObjectLoadingContent.PLUGIN_OUTDATED:
return "PluginOutdated";
case Ci.nsIObjectLoadingContent.PLUGIN_CLICK_TO_PLAY:
case Ci.nsIObjectLoadingContent.PLUGIN_CLICK_TO_PLAY_QUIET:
return "PluginClickToPlay";
case Ci.nsIObjectLoadingContent.PLUGIN_VULNERABLE_UPDATABLE:
return "PluginVulnerableUpdatable";
case Ci.nsIObjectLoadingContent.PLUGIN_VULNERABLE_NO_UPDATE:
return "PluginVulnerableNoUpdate";
default:
// Not all states map to a handler
return null;
}
}
handleEvent(event) {
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
// Ignore events for other frames.
let eventDoc = event.target.ownerDocument || event.target.document;
if (eventDoc && eventDoc != this.document) {
return;
}
if (!this._addedListeners) {
// Only add pageshow/pagehide listeners here. We don't want this actor
// to be instantiated for every frame, we only care if a plugin actually
// gets used in a frame. So we don't add these listeners in the actor
// specification, but only at runtime once one of our Plugin* events
// fires.
this.contentWindow.addEventListener("pagehide", this, {
capture: true,
mozSystemGroup: true,
});
this.contentWindow.addEventListener("pageshow", this, {
capture: true,
mozSystemGroup: true,
});
this._addedListeners = true;
}
let eventType = event.type;
if (eventType == "pagehide") {
this.onPageHide(event);
return;
}
if (eventType == "pageshow") {
this.onPageShow(event);
return;
}
if (eventType == "click") {
this.onOverlayClick(event);
return;
}
if (
eventType == "PluginCrashed" &&
!(event.target instanceof Ci.nsIObjectLoadingContent)
) {
// If the event target is not a plugin object (i.e., an <object> or
// <embed> element), this call is for a window-global plugin.
this.onPluginCrashed(event.target, event);
return;
}
if (eventType == "HiddenPlugin") {
let pluginTag = event.tag.QueryInterface(Ci.nsIPluginTag);
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
this.showClickToPlayNotification(pluginTag, false);
}
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 pluginElement = event.target;
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 (!(pluginElement instanceof Ci.nsIObjectLoadingContent)) {
return;
}
if (eventType == "PluginBindingAttached") {
// The plugin binding fires this event when it is created.
// As an untrusted event, ensure that this object actually has a binding
// and make sure we don't handle it twice
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 overlay = this.getPluginUI(pluginElement, "main");
if (!overlay || overlay._bindingHandled) {
return;
}
overlay._bindingHandled = true;
// Lookup the handler for this binding
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
eventType = this._getBindingType(pluginElement);
if (!eventType) {
// Not all bindings have handlers
return;
}
}
let shouldShowNotification = false;
switch (eventType) {
case "PluginCrashed":
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
this.onPluginCrashed(pluginElement, event);
break;
case "PluginNotFound": {
2014-09-18 21:01:23 +04:00
/* NOP */
break;
}
case "PluginBlocklisted":
case "PluginOutdated":
shouldShowNotification = true;
break;
case "PluginVulnerableUpdatable":
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 updateLink = this.getPluginUI(pluginElement, "checkForUpdatesLink");
let { pluginTag } = this._getPluginInfo(pluginElement);
this.addLinkClickCallback(
updateLink,
"forwardCallback",
"openPluginUpdatePage",
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
pluginTag.id
);
/* FALLTHRU */
case "PluginVulnerableNoUpdate":
case "PluginClickToPlay":
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
this._handleClickToPlayEvent(pluginElement);
let { pluginName } = this._getPluginInfo(pluginElement);
let messageString = gNavigatorBundle.formatStringFromName(
"PluginClickToActivate2",
[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
let overlayText = this.getPluginUI(pluginElement, "clickToPlay");
overlayText.textContent = messageString;
if (
eventType == "PluginVulnerableUpdatable" ||
eventType == "PluginVulnerableNoUpdate"
) {
let vulnerabilityString = gNavigatorBundle.GetStringFromName(
eventType
);
let vulnerabilityText = this.getPluginUI(
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
pluginElement,
"vulnerabilityStatus"
);
vulnerabilityText.textContent = vulnerabilityString;
}
shouldShowNotification = true;
break;
case "PluginDisabled":
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 manageLink = this.getPluginUI(pluginElement, "managePluginsLink");
this.addLinkClickCallback(
manageLink,
"forwardCallback",
"managePlugins"
);
shouldShowNotification = true;
break;
case "PluginInstantiated":
shouldShowNotification = true;
break;
}
// Show the in-content UI if it's not too big. The crashed plugin handler already did this.
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 overlay = this.getPluginUI(pluginElement, "main");
if (eventType != "PluginCrashed") {
if (overlay != null) {
this.setVisibility(
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
pluginElement,
overlay,
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
this.computeAndAdjustOverlayDisplay(pluginElement, overlay, false)
);
let resizeListener = () => {
this.setVisibility(
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
pluginElement,
overlay,
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
this.computeAndAdjustOverlayDisplay(pluginElement, overlay, true)
);
};
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
pluginElement.addEventListener("overflow", resizeListener);
pluginElement.addEventListener("underflow", resizeListener);
}
}
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 closeIcon = this.getPluginUI(pluginElement, "closeIcon");
if (closeIcon) {
closeIcon.addEventListener(
"click",
clickEvent => {
if (clickEvent.button == 0 && clickEvent.isTrusted) {
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
this.hideClickToPlayOverlay(pluginElement);
overlay.setAttribute("dismissed", "true");
}
},
true
);
}
if (shouldShowNotification) {
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
this.showClickToPlayNotification(pluginElement, false);
}
}
isKnownPlugin(objLoadingContent) {
return (
objLoadingContent.getContentTypeForMIMEType(
objLoadingContent.actualType
) == Ci.nsIObjectLoadingContent.TYPE_PLUGIN
);
}
canActivatePlugin(objLoadingContent) {
// if this isn't a known plugin, we can't activate it
// (this also guards pluginHost.getPermissionStringForType against
// unexpected input)
if (!this.isKnownPlugin(objLoadingContent)) {
return false;
}
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 permissionString = gPluginHost.getPermissionStringForType(
objLoadingContent.actualType
);
let principal = objLoadingContent.ownerGlobal.top.document.nodePrincipal;
let pluginPermission = Services.perms.testPermissionFromPrincipal(
principal,
permissionString
);
let isFallbackTypeValid =
objLoadingContent.pluginFallbackType >=
Ci.nsIObjectLoadingContent.PLUGIN_CLICK_TO_PLAY &&
objLoadingContent.pluginFallbackType <=
Ci.nsIObjectLoadingContent.PLUGIN_CLICK_TO_PLAY_QUIET;
return (
!objLoadingContent.activated &&
pluginPermission != Ci.nsIPermissionManager.DENY_ACTION &&
isFallbackTypeValid
);
}
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
hideClickToPlayOverlay(pluginElement) {
let overlay = this.getPluginUI(pluginElement, "main");
if (overlay) {
overlay.classList.remove("visible");
}
}
// Forward a link click callback to the chrome process.
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
forwardCallback(name, pluginId) {
this.sendAsyncMessage("PluginContent:LinkClickCallback", {
name,
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
pluginId,
});
}
submitReport(plugin) {
if (!AppConstants.MOZ_CRASHREPORTER) {
return;
}
if (!plugin) {
Cu.reportError(
"Attempted to submit crash report without an associated plugin."
);
return;
}
if (!(plugin instanceof Ci.nsIObjectLoadingContent)) {
Cu.reportError(
"Attempted to submit crash report on plugin that does not" +
"implement nsIObjectLoadingContent."
);
return;
}
let runID = plugin.runID;
let submitURLOptIn = this.getPluginUI(plugin, "submitURLOptIn").checked;
let keyVals = {};
let userComment = this.getPluginUI(plugin, "submitComment").value.trim();
if (userComment) {
keyVals.PluginUserComment = userComment;
}
if (submitURLOptIn) {
keyVals.PluginContentURL = plugin.ownerDocument.URL;
}
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
this.sendAsyncMessage("PluginContent:SubmitReport", {
runID,
keyVals,
submitURLOptIn,
});
}
reloadPage() {
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
this.contentWindow.location.reload();
}
// Event listener for click-to-play plugins.
_handleClickToPlayEvent(plugin) {
let doc = plugin.ownerDocument;
// guard against giving pluginHost.getPermissionStringForType a type
// not associated with any known plugin
if (!this.isKnownPlugin(plugin)) {
return;
}
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 permissionString = gPluginHost.getPermissionStringForType(
plugin.actualType
);
let principal = doc.defaultView.top.document.nodePrincipal;
let pluginPermission = Services.perms.testPermissionFromPrincipal(
principal,
permissionString
);
let overlay = this.getPluginUI(plugin, "main");
if (
pluginPermission == Ci.nsIPermissionManager.DENY_ACTION ||
pluginPermission ==
Ci.nsIObjectLoadingContent.PLUGIN_PERMISSION_PROMPT_ACTION_QUIET
) {
if (overlay) {
overlay.classList.remove("visible");
}
return;
}
if (overlay) {
overlay.addEventListener("click", this, true);
}
}
onOverlayClick(event) {
let plugin = event.target.containingShadowRoot.host;
let overlay = this.getPluginUI(plugin, "main");
// Have to check that the target is not the link to update the plugin
if (
!(
ChromeUtils.getClassName(event.originalTarget) === "HTMLAnchorElement"
) &&
Bug 1497940 - Part V, Convert pluginProblem to UA Widget r=smaug This patch creates a pluginProblem UA Widget and constructs it (instead of the XBL pluginProblem binding) when UA Widget is enabled. Tests in browser/base/content/test/plugins/ are duplicated so that we could test both versions. Depends on D11702 Differential Revision: https://phabricator.services.mozilla.com/D11703 --HG-- rename : browser/base/content/test/plugins/.eslintrc.js => browser/base/content/test/plugins/xbl/.eslintrc.js rename : browser/base/content/test/plugins/blockNoPlugins.xml => browser/base/content/test/plugins/xbl/blockNoPlugins.xml rename : browser/base/content/test/plugins/blockPluginHard.xml => browser/base/content/test/plugins/xbl/blockPluginHard.xml rename : browser/base/content/test/plugins/blockPluginInfoURL.xml => browser/base/content/test/plugins/xbl/blockPluginInfoURL.xml rename : browser/base/content/test/plugins/blockPluginVulnerableNoUpdate.xml => browser/base/content/test/plugins/xbl/blockPluginVulnerableNoUpdate.xml rename : browser/base/content/test/plugins/blockPluginVulnerableUpdatable.xml => browser/base/content/test/plugins/xbl/blockPluginVulnerableUpdatable.xml rename : browser/base/content/test/plugins/blocklist_proxy.js => browser/base/content/test/plugins/xbl/blocklist_proxy.js rename : browser/base/content/test/plugins/browser.ini => browser/base/content/test/plugins/xbl/browser.ini rename : browser/base/content/test/plugins/browser_CTP_context_menu.js => browser/base/content/test/plugins/xbl/browser_CTP_context_menu.js rename : browser/base/content/test/plugins/browser_CTP_crashreporting.js => browser/base/content/test/plugins/xbl/browser_CTP_crashreporting.js rename : browser/base/content/test/plugins/browser_CTP_drag_drop.js => browser/base/content/test/plugins/xbl/browser_CTP_drag_drop.js rename : browser/base/content/test/plugins/browser_CTP_favorfallback.js => browser/base/content/test/plugins/xbl/browser_CTP_favorfallback.js rename : browser/base/content/test/plugins/browser_CTP_hide_overlay.js => browser/base/content/test/plugins/xbl/browser_CTP_hide_overlay.js rename : browser/base/content/test/plugins/browser_CTP_iframe.js => browser/base/content/test/plugins/xbl/browser_CTP_iframe.js rename : browser/base/content/test/plugins/browser_CTP_nonplugins.js => browser/base/content/test/plugins/xbl/browser_CTP_nonplugins.js rename : browser/base/content/test/plugins/browser_CTP_outsideScrollArea.js => browser/base/content/test/plugins/xbl/browser_CTP_outsideScrollArea.js rename : browser/base/content/test/plugins/browser_CTP_overlay_styles.js => browser/base/content/test/plugins/xbl/browser_CTP_overlay_styles.js rename : browser/base/content/test/plugins/browser_CTP_resize.js => browser/base/content/test/plugins/xbl/browser_CTP_resize.js rename : browser/base/content/test/plugins/browser_CTP_shouldShowOverlay.js => browser/base/content/test/plugins/xbl/browser_CTP_shouldShowOverlay.js rename : browser/base/content/test/plugins/browser_CTP_zoom.js => browser/base/content/test/plugins/xbl/browser_CTP_zoom.js rename : browser/base/content/test/plugins/browser_blocking.js => browser/base/content/test/plugins/xbl/browser_blocking.js rename : browser/base/content/test/plugins/browser_blocklist_content.js => browser/base/content/test/plugins/xbl/browser_blocklist_content.js rename : browser/base/content/test/plugins/browser_bug743421.js => browser/base/content/test/plugins/xbl/browser_bug743421.js rename : browser/base/content/test/plugins/browser_bug744745.js => browser/base/content/test/plugins/xbl/browser_bug744745.js rename : browser/base/content/test/plugins/browser_bug787619.js => browser/base/content/test/plugins/xbl/browser_bug787619.js rename : browser/base/content/test/plugins/browser_bug797677.js => browser/base/content/test/plugins/xbl/browser_bug797677.js rename : browser/base/content/test/plugins/browser_bug812562.js => browser/base/content/test/plugins/xbl/browser_bug812562.js rename : browser/base/content/test/plugins/browser_bug818118.js => browser/base/content/test/plugins/xbl/browser_bug818118.js rename : browser/base/content/test/plugins/browser_bug820497.js => browser/base/content/test/plugins/xbl/browser_bug820497.js rename : browser/base/content/test/plugins/browser_clearplugindata.html => browser/base/content/test/plugins/xbl/browser_clearplugindata.html rename : browser/base/content/test/plugins/browser_clearplugindata.js => browser/base/content/test/plugins/xbl/browser_clearplugindata.js rename : browser/base/content/test/plugins/browser_clearplugindata_noage.html => browser/base/content/test/plugins/xbl/browser_clearplugindata_noage.html rename : browser/base/content/test/plugins/browser_enable_DRM_prompt.js => browser/base/content/test/plugins/xbl/browser_enable_DRM_prompt.js rename : browser/base/content/test/plugins/browser_globalplugin_crashinfobar.js => browser/base/content/test/plugins/xbl/browser_globalplugin_crashinfobar.js rename : browser/base/content/test/plugins/browser_iterate_hidden_plugins.js => browser/base/content/test/plugins/xbl/browser_iterate_hidden_plugins.js rename : browser/base/content/test/plugins/browser_pluginCrashCommentAndURL.js => browser/base/content/test/plugins/xbl/browser_pluginCrashCommentAndURL.js rename : browser/base/content/test/plugins/browser_pluginCrashReportNonDeterminism.js => browser/base/content/test/plugins/xbl/browser_pluginCrashReportNonDeterminism.js rename : browser/base/content/test/plugins/browser_plugin_reloading.js => browser/base/content/test/plugins/xbl/browser_plugin_reloading.js rename : browser/base/content/test/plugins/browser_pluginnotification.js => browser/base/content/test/plugins/xbl/browser_pluginnotification.js rename : browser/base/content/test/plugins/browser_private_browsing_eme_persistent_state.js => browser/base/content/test/plugins/xbl/browser_private_browsing_eme_persistent_state.js rename : browser/base/content/test/plugins/browser_private_clicktoplay.js => browser/base/content/test/plugins/xbl/browser_private_clicktoplay.js rename : browser/base/content/test/plugins/browser_subframe_access_hidden_plugins.js => browser/base/content/test/plugins/xbl/browser_subframe_access_hidden_plugins.js rename : browser/base/content/test/plugins/empty_file.html => browser/base/content/test/plugins/xbl/empty_file.html rename : browser/base/content/test/plugins/plugin_add_dynamically.html => browser/base/content/test/plugins/xbl/plugin_add_dynamically.html rename : browser/base/content/test/plugins/plugin_alternate_content.html => browser/base/content/test/plugins/xbl/plugin_alternate_content.html rename : browser/base/content/test/plugins/plugin_big.html => browser/base/content/test/plugins/xbl/plugin_big.html rename : browser/base/content/test/plugins/plugin_both.html => browser/base/content/test/plugins/xbl/plugin_both.html rename : browser/base/content/test/plugins/plugin_both2.html => browser/base/content/test/plugins/xbl/plugin_both2.html rename : browser/base/content/test/plugins/plugin_bug744745.html => browser/base/content/test/plugins/xbl/plugin_bug744745.html rename : browser/base/content/test/plugins/plugin_bug749455.html => browser/base/content/test/plugins/xbl/plugin_bug749455.html rename : browser/base/content/test/plugins/plugin_bug787619.html => browser/base/content/test/plugins/xbl/plugin_bug787619.html rename : browser/base/content/test/plugins/plugin_bug797677.html => browser/base/content/test/plugins/xbl/plugin_bug797677.html rename : browser/base/content/test/plugins/plugin_bug820497.html => browser/base/content/test/plugins/xbl/plugin_bug820497.html rename : browser/base/content/test/plugins/plugin_clickToPlayAllow.html => browser/base/content/test/plugins/xbl/plugin_clickToPlayAllow.html rename : browser/base/content/test/plugins/plugin_clickToPlayDeny.html => browser/base/content/test/plugins/xbl/plugin_clickToPlayDeny.html rename : browser/base/content/test/plugins/plugin_crashCommentAndURL.html => browser/base/content/test/plugins/xbl/plugin_crashCommentAndURL.html rename : browser/base/content/test/plugins/plugin_favorfallback.html => browser/base/content/test/plugins/xbl/plugin_favorfallback.html rename : browser/base/content/test/plugins/plugin_hidden_to_visible.html => browser/base/content/test/plugins/xbl/plugin_hidden_to_visible.html rename : browser/base/content/test/plugins/plugin_iframe.html => browser/base/content/test/plugins/xbl/plugin_iframe.html rename : browser/base/content/test/plugins/plugin_outsideScrollArea.html => browser/base/content/test/plugins/xbl/plugin_outsideScrollArea.html rename : browser/base/content/test/plugins/plugin_overlay_styles.html => browser/base/content/test/plugins/xbl/plugin_overlay_styles.html rename : browser/base/content/test/plugins/plugin_shouldShowOverlay.html => browser/base/content/test/plugins/xbl/plugin_shouldShowOverlay.html rename : browser/base/content/test/plugins/plugin_simple_blank.swf => browser/base/content/test/plugins/xbl/plugin_simple_blank.swf rename : browser/base/content/test/plugins/plugin_small.html => browser/base/content/test/plugins/xbl/plugin_small.html rename : browser/base/content/test/plugins/plugin_small_2.html => browser/base/content/test/plugins/xbl/plugin_small_2.html rename : browser/base/content/test/plugins/plugin_syncRemoved.html => browser/base/content/test/plugins/xbl/plugin_syncRemoved.html rename : browser/base/content/test/plugins/plugin_test.html => browser/base/content/test/plugins/xbl/plugin_test.html rename : browser/base/content/test/plugins/plugin_test2.html => browser/base/content/test/plugins/xbl/plugin_test2.html rename : browser/base/content/test/plugins/plugin_test3.html => browser/base/content/test/plugins/xbl/plugin_test3.html rename : browser/base/content/test/plugins/plugin_two_types.html => browser/base/content/test/plugins/xbl/plugin_two_types.html rename : browser/base/content/test/plugins/plugin_unknown.html => browser/base/content/test/plugins/xbl/plugin_unknown.html rename : browser/base/content/test/plugins/plugin_zoom.html => browser/base/content/test/plugins/xbl/plugin_zoom.html rename : toolkit/pluginproblem/content/pluginProblem.xml => toolkit/content/widgets/pluginProblem.js extra : moz-landing-system : lando
2018-11-22 08:49:54 +03:00
event.originalTarget.getAttribute("anonid") != "closeIcon" &&
event.originalTarget.id != "closeIcon" &&
!overlay.hasAttribute("dismissed") &&
event.button == 0 &&
event.isTrusted
) {
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
this.showClickToPlayNotification(plugin, true);
event.stopPropagation();
event.preventDefault();
}
}
reshowClickToPlayNotification() {
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 { plugins } = this.contentWindow.windowUtils;
for (let plugin of plugins) {
let overlay = this.getPluginUI(plugin, "main");
if (overlay) {
overlay.removeEventListener("click", this, true);
}
if (this.canActivatePlugin(plugin)) {
this._handleClickToPlayEvent(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
this.showClickToPlayNotification(null, false);
}
/**
* Activate the plugins that the user has specified.
*/
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
activatePlugins(activationInfo, newState) {
let { plugins } = this.contentWindow.windowUtils;
let pluginFound = false;
for (let plugin of plugins) {
if (!this.isKnownPlugin(plugin)) {
continue;
}
if (
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
activationInfo.permissionString ==
gPluginHost.getPermissionStringForType(plugin.actualType)
) {
let overlay = this.getPluginUI(plugin, "main");
pluginFound = true;
if (
newState == "block" ||
newState == "blockalways" ||
newState == "continueblocking"
) {
if (overlay) {
overlay.addEventListener("click", this, true);
}
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
plugin.pluginFallbackTypeOverride = activationInfo.fallbackType;
plugin.reload(true);
} else if (this.canActivatePlugin(plugin)) {
if (overlay) {
overlay.removeEventListener("click", this, true);
}
plugin.playPlugin();
}
}
}
// If there are no instances of the plugin on the page any more or if we've
// noted that the content needs to be reloaded due to replacing HLS, what the
// user probably needs is for us to allow and then refresh.
if (
newState != "block" &&
newState != "blockalways" &&
newState != "continueblocking" &&
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
(!pluginFound || this.contentWindow.pluginRequiresReload)
) {
this.reloadPage();
}
}
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
showClickToPlayNotification(pluginElOrTag, showNow) {
let plugins = [];
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 pluginElOrTag is null, that means the user has navigated back to a page with
// plugins, and we need to collect all the plugins.
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 (pluginElOrTag === null) {
// cwu.plugins may contain non-plugin <object>s, filter them out
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
plugins = this.contentWindow.windowUtils.plugins.filter(
p =>
p.getContentTypeForMIMEType(p.actualType) ==
Ci.nsIObjectLoadingContent.TYPE_PLUGIN
);
if (!plugins.length) {
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
this.removeNotification();
return;
}
} else {
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
plugins = [pluginElOrTag];
}
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
// Iterate over the plugins and ensure we have one value for each
// permission string - though in principle there should only be 1 anyway
// (for flash), in practice there are still some automated tests where we
// could encounter other ones.
let permissionMap = new Map();
for (let p of plugins) {
let pluginInfo;
if (p instanceof Ci.nsIPluginTag) {
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
pluginInfo = this._getPluginInfoForTag(p);
} else {
pluginInfo = this._getPluginInfo(p);
}
if (pluginInfo.permissionString === null) {
Cu.reportError("No permission string for active plugin.");
continue;
}
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 (!permissionMap.has(pluginInfo.permissionString)) {
permissionMap.set(pluginInfo.permissionString, pluginInfo);
continue;
}
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 (permissionMap.size > 1) {
Cu.reportError(
"Err, we're not meant to have more than 1 plugin anymore!"
);
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 (!permissionMap.size) {
return;
}
this.haveShownNotification = true;
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 permissionItem = permissionMap.values().next().value;
let plugin = {
id: permissionItem.pluginTag.id,
fallbackType: permissionItem.fallbackType,
};
let msg = "PluginContent:ShowClickToPlayNotification";
this.sendAsyncMessage(msg, { plugin, showNow });
}
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
removeNotification() {
this.sendAsyncMessage("PluginContent:RemoveNotification");
}
clearPluginCaches() {
this.pluginCrashData.clear();
}
/**
* Determines whether or not the crashed plugin is contained within current
* full screen DOM element.
* @param fullScreenElement (DOM element)
* The DOM element that is currently full screen, or null.
* @param domElement
* The DOM element which contains the crashed plugin, or the crashed plugin
* itself.
* @returns bool
* True if the plugin is a descendant of the full screen DOM element, false otherwise.
**/
isWithinFullScreenElement(fullScreenElement, domElement) {
/**
* Traverses down iframes until it find a non-iframe full screen DOM element.
* @param fullScreenIframe
* Target iframe to begin searching from.
* @returns DOM element
* The full screen DOM element contained within the iframe (could be inner iframe), or the original iframe if no inner DOM element is found.
**/
let getTrueFullScreenElement = fullScreenIframe => {
if (
typeof fullScreenIframe.contentDocument !== "undefined" &&
fullScreenIframe.contentDocument.mozFullScreenElement
) {
return getTrueFullScreenElement(
fullScreenIframe.contentDocument.mozFullScreenElement
);
}
return fullScreenIframe;
};
if (fullScreenElement.tagName === "IFRAME") {
fullScreenElement = getTrueFullScreenElement(fullScreenElement);
}
if (fullScreenElement.contains(domElement)) {
return true;
}
let parentIframe = domElement.ownerGlobal.frameElement;
if (parentIframe) {
return this.isWithinFullScreenElement(fullScreenElement, parentIframe);
}
return false;
}
/**
* The PluginCrashed event handler. Note that the PluginCrashed event is
* fired for both NPAPI and Gecko Media plugins. In the latter case, the
* target of the event is the document that the GMP is being used in.
*/
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
async onPluginCrashed(target, aEvent) {
if (!(aEvent instanceof this.contentWindow.PluginCrashedEvent)) {
return;
}
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 fullScreenElement = this.contentWindow.top.document
.mozFullScreenElement;
if (fullScreenElement) {
if (this.isWithinFullScreenElement(fullScreenElement, target)) {
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
this.contentWindow.top.document.mozCancelFullScreen();
}
}
if (aEvent.gmpPlugin) {
this.GMPCrashed(aEvent);
return;
}
if (!(target instanceof Ci.nsIObjectLoadingContent)) {
return;
}
let crashData = this.pluginCrashData.get(target.runID);
if (!crashData) {
// We haven't received information from the parent yet about
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
// this crash, so go get it:
crashData = await this.sendQuery("PluginContent:GetCrashData", {
runID: target.runID,
});
this.pluginCrashData.set(target.runID, crashData);
}
this.setCrashedNPAPIPluginState({
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
pluginElement: target,
state: crashData.state,
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
pluginName: crashData.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
setCrashedNPAPIPluginState({ pluginElement, state, pluginName }) {
let overlay = this.getPluginUI(pluginElement, "main");
let statusDiv = this.getPluginUI(pluginElement, "submitStatus");
let optInCB = this.getPluginUI(pluginElement, "submitURLOptIn");
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
this.getPluginUI(pluginElement, "submitButton").addEventListener(
"click",
event => {
if (event.button != 0 || !event.isTrusted) {
return;
}
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
this.submitReport(pluginElement);
}
);
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
optInCB.checked = Services.prefs.getBoolPref(
"dom.ipc.plugins.reportCrashURL",
true
);
statusDiv.setAttribute("status", state);
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 helpIcon = this.getPluginUI(pluginElement, "helpIcon");
this.addLinkClickCallback(helpIcon, "openHelpPage");
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 crashText = this.getPluginUI(pluginElement, "crashedText");
let message = gNavigatorBundle.formatStringFromName(
"crashedpluginsMessage.title",
[pluginName]
);
crashText.textContent = message;
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 link = this.getPluginUI(pluginElement, "reloadLink");
this.addLinkClickCallback(link, "reloadPage");
// This might trigger force reflow, but plug-in crashing code path shouldn't be hot.
let overlayDisplayState = this.computeAndAdjustOverlayDisplay(
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
pluginElement,
overlay,
true
);
// Is the <object>'s size too small to hold what we want to show?
if (overlayDisplayState != OVERLAY_DISPLAY.FULL) {
// First try hiding the crash report submission UI.
statusDiv.removeAttribute("status");
overlayDisplayState = this.computeAndAdjustOverlayDisplay(
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
pluginElement,
overlay,
true
);
}
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
this.setVisibility(pluginElement, overlay, overlayDisplayState);
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 doc = pluginElement.ownerDocument;
let runID = pluginElement.runID;
if (overlayDisplayState == OVERLAY_DISPLAY.FULL) {
doc.mozNoPluginCrashedNotification = true;
// Notify others that the crash reporter UI is now ready.
// Currently, this event is only used by tests.
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 winUtils = this.contentWindow.windowUtils;
let event = new this.contentWindow.CustomEvent(
"PluginCrashReporterDisplayed",
{
bubbles: true,
}
);
winUtils.dispatchEventToChromeOnly(pluginElement, event);
} else if (!doc.mozNoPluginCrashedNotification) {
// If another plugin on the page was large enough to show our UI, we don't
// want to show a notification bar.
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
this.sendAsyncMessage("PluginContent:ShowPluginCrashedNotification", {
pluginCrashID: { runID },
});
}
}
NPAPIPluginCrashReportSubmitted({ runID, state }) {
this.pluginCrashData.delete(runID);
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 { plugins } = this.contentWindow.windowUtils;
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
for (let pluginElement of plugins) {
if (
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
pluginElement instanceof Ci.nsIObjectLoadingContent &&
pluginElement.runID == runID
) {
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 statusDiv = this.getPluginUI(pluginElement, "submitStatus");
statusDiv.setAttribute("status", state);
}
}
}
GMPCrashed(aEvent) {
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 { target, gmpPlugin, pluginID } = aEvent;
if (!gmpPlugin || !target.document) {
// TODO: Throw exception? How did we get here?
return;
}
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
this.sendAsyncMessage("PluginContent:ShowPluginCrashedNotification", {
pluginCrashID: { pluginID },
});
}
}