@gl can you take a look at the DevTools test added here?
@nika @mconley I used this.browsingContext.docShell.isContent here to rule out chrome-privileged documents. Do you know if there is better way to check if the current document is chrome-privileged or not?
Differential Revision: https://phabricator.services.mozilla.com/D51320
--HG--
extra : moz-landing-system : lando
Depends on D49941
Using ContentDOMReference instead of creating an array of selectors makes inspect element more stable in case the page is modified between after the contextmenu opens.
It will also make the feature easier to make fission compatible
Differential Revision: https://phabricator.services.mozilla.com/D49303
--HG--
extra : moz-landing-system : lando
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
Bug 1587521 - Enable FullScreen in FxR for Desktop
This change enables Fullscreen functionality in the UI for Firefox Reality for Desktop. On Fullscreen, the window (rather than the desktop) is taken over, and it is up to the host to render the contents as fullscreen.
To mitigate the impact on Desktop's implementation, browser-fullScreenAndPointerLock.js is forked and removes the dependencies on browser.js. These two files will be rationalized at a later time.
Differential Revision: https://phabricator.services.mozilla.com/D48913
--HG--
rename : browser/base/content/browser-fullScreenAndPointerLock.js => browser/fxr/content/fxr-fullScreen.js
extra : moz-landing-system : lando
e10s scenario:
1. An DOM element request fulscreen mode.
2. The request is redirected to the parent.
3. Parent enters fullscreen.
4. Parent notifies child that it has finished entering fullscreen.
5. Child goes fullscreen.
6. Then, child notifies parent that it has finished transitioning to fullscreen.
4. Finally, parent notify observers that fullscreen paint has finished.
Let's go into the details of how step 5 works in the above scenario.
5.a The element that made the request is set to fullscreen.
5.b Then, the document where that element lives is set to fullscreen as well as all of its ancestors until we reach the top level document. (see Document::ApplyFulscreen method)
Now in Fission world, we may have a request comming from an oop iframe. And it that case since we won't have to ancestor documents living in different content process(es), we will first notiy those content processes (one after another from bottom to top) to go fullscreen. Once they all do, the content process where the request originated will be told to enter fullscreen.
Differential Revision: https://phabricator.services.mozilla.com/D45972
--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
