These actors handle implementation of alternative stylesheets functionality.
r=mconley,Gijs
Differential Revision: https://phabricator.services.mozilla.com/D46861
--HG--
extra : moz-landing-system : lando
At this point, fullscreen is not regressed but it doesn't work with oop iframes yet.
Differential Revision: https://phabricator.services.mozilla.com/D35026
--HG--
extra : moz-landing-system : lando
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
This patch implements the window letterboxing. The implementation
is based on adding margins around the browser element to round the
content viewport size. Whenever the browser content is resized, the
RFPHelper will adjust margins around it. But it won't add any margins
for an empty browser or a browser loads a content with the system
principal.
The letterboxing is hidden behind a hidden pref
"privacy.resistFingerprinting.letterboxing." By default, it will use
stepping size 200x100 to round content window. And we can customize
the set of dimensions used for deciding the size of the rounded
content viewport by the pref
"privacy.resistFingerprinting.letterboxing.dimensions". This pref
should be formated as 'width1xheight1, width2xheight2, ...'. We will
find the dimensions which can fit into the real content size and have
the smallest margins to be the rounded content viewport size. For example
, given the set "400x200, 500x300, 800x500" and the real content size
"600x300", we would round the content size into 500x300.
--HG--
extra : histedit_source : 4d4ced7e899f4f3cae25e11d30cc24a4f1b9e0e7
This patch implements the window letterboxing. The implementation
is based on adding margins around the browser element to round the
content viewport size. Whenever the browser content is resized, the
RFPHelper will adjust margins around it. But it won't add any margins
for an empty browser or a browser loads a content with the system
principal.
The letterboxing is hidden behind a hidden pref
"privacy.resistFingerprinting.letterboxing." By default, it will use
stepping size 200x100 to round content window. And we can customize
the set of dimensions used for deciding the size of the rounded
content viewport by the pref
"privacy.resistFingerprinting.letterboxing.dimensions". This pref
should be formated as 'width1xheight1, width2xheight2, ...'. We will
find the dimensions which can fit into the real content size and have
the smallest margins to be the rounded content viewport size. For example
, given the set "400x200, 500x300, 800x500" and the real content size
"600x300", we would round the content size into 500x300.
--HG--
extra : rebase_source : a5bcb64934177f8518ef4bca922d7e3330bbd3ca
This moves UAWidgetsChild.jsm from browser to toolkit so that
Fennec and Reftest could pick it up.
Differential Revision: https://phabricator.services.mozilla.com/D5085
--HG--
rename : browser/actors/UAWidgetsChild.jsm => toolkit/actors/UAWidgetsChild.jsm
extra : moz-landing-system : lando