1. 23 Aug, 2019 1 commit
    • Andrew Swan's avatar
      Bug 1567258 - Convert fxmonitor to a built-in component r=nhnt11,flod · d697e6aa
      Andrew Swan authored
      Differential Revision: https://phabricator.services.mozilla.com/D40666
      
      --HG--
      rename : browser/extensions/fxmonitor/privileged/api.js => browser/components/fxmonitor/FirefoxMonitor.jsm
      rename : browser/extensions/fxmonitor/privileged/FirefoxMonitor.css => browser/components/fxmonitor/content/FirefoxMonitor.css
      rename : browser/extensions/fxmonitor/assets/monitor32.svg => browser/components/fxmonitor/content/monitor32.svg
      rename : browser/extensions/fxmonitor/moz.build => browser/components/fxmonitor/moz.build
      rename : browser/extensions/fxmonitor/test/browser/browser.ini => browser/components/fxmonitor/test/browser/browser.ini
      rename : browser/extensions/fxmonitor/test/browser/browser_fxmonitor_doorhanger.js => browser/components/fxmonitor/test/browser/browser_fxmonitor_doorhanger.js
      rename : browser/extensions/fxmonitor/locales/en-US/fxmonitor.properties => browser/locales/en-US/chrome/browser/fxmonitor.properties
      extra : moz-landing-system : lando
      d697e6aa
  2. 20 Aug, 2019 1 commit
  3. 19 Aug, 2019 1 commit
  4. 16 Aug, 2019 2 commits
  5. 15 Aug, 2019 2 commits
  6. 19 Aug, 2019 1 commit
  7. 14 Aug, 2019 2 commits
  8. 15 Aug, 2019 1 commit
  9. 14 Aug, 2019 2 commits
  10. 12 Aug, 2019 3 commits
  11. 09 Aug, 2019 1 commit
    • Alastor Wu's avatar
      Bug 1567302 - add a Telemetry ping to record the deault setting of blocking... · 9f6ad187
      Alastor Wu authored
      Bug 1567302 - add a Telemetry ping to record the deault setting of blocking autoplay. r=janerik,daleharvey
      
      We acutally have an old Telemetry ping `autoplay_default_blocked`, which, however, has been removed incorrectly in bug1356046.
      
      As we have extended the setting options of blocking autoplay in bug1543812, it's also no longer proper to use scalar to store it.
      
      Therefore, create an new histogram Telemetry ping to store the number of times a user changed the default autoplay behavior to each setting during a subsession.
      
      Differential Revision: https://phabricator.services.mozilla.com/D40890
      
      --HG--
      extra : moz-landing-system : lando
      9f6ad187
  12. 20 Aug, 2019 1 commit
  13. 09 Aug, 2019 1 commit
  14. 13 Aug, 2019 1 commit
  15. 06 Aug, 2019 1 commit
  16. 08 Aug, 2019 2 commits
  17. 09 Aug, 2019 1 commit
  18. 05 Aug, 2019 2 commits
  19. 15 Aug, 2019 1 commit
  20. 31 Jul, 2019 4 commits
  21. 30 Jul, 2019 4 commits
  22. 26 Jul, 2019 1 commit
  23. 25 Jul, 2019 2 commits
  24. 23 Jul, 2019 2 commits
    • Gijs Kruitbosch's avatar
      Bug 1505913 - make plugin click-to-play and crash handling fission-compatible, r=mconley · fffc7f0c
      Gijs Kruitbosch authored
      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
      fffc7f0c
    • mcrawford@mozilla.com's avatar
      68ac43af