1. 09 Sep, 2020 5 commits
  2. 08 Sep, 2020 2 commits
  3. 25 Aug, 2020 1 commit
  4. 08 Sep, 2020 5 commits
  5. 02 Sep, 2020 1 commit
  6. 07 Sep, 2020 2 commits
  7. 06 Sep, 2020 1 commit
  8. 07 Sep, 2020 1 commit
  9. 06 Sep, 2020 1 commit
    • Emilio Cobos Álvarez's avatar
      Bug 1663140 - Don't block on window.print() if there are print callbacks. r=smaug, a=RyanVM · 6eae8df6
      Emilio Cobos Álvarez authored
      Not really a fan of this, but I can't think of a better alternative
      really... Ideas welcome :)
      The main issue is that in bug 1662975 we made window.print() not return
      until the user has closed the print / print preview dialog (as it is
      needed for some use cases). This matches other browsers, too.
      We use an nsAutoSyncOperation here, in order not to violate the
      run-to-completion invariants, which turns off micro-tasks, timers,
      etc... However we'd still want promises inside mozPrintCallback to
      resolve and such, which is a bit contradictory. It is really awkward to
      have this behavior change based on whether we have a print callback...
      Differential Revision: https://phabricator.services.mozilla.com/D89298
  10. 04 Sep, 2020 1 commit
  11. 02 Sep, 2020 2 commits
  12. 28 Aug, 2020 2 commits
  13. 02 Sep, 2020 2 commits
    • Nicolas Chevobbe's avatar
      Bug 1660466 - Fix attaching target/thread test intermittents. r=jdescottes, a=RyanVM · 7c81f0a2
      Nicolas Chevobbe authored
      Move the function taking care of closing the Browser Console to shared-head so
      we can close it before closing the tabs opened during the test.
      While attaching the worker, check that the Worker Debugger isn't closed, and
      if it is, reject the promise. On the target list, catch rejection while attaching
      and simply bail out so we don't call the rest of the code in onTargetAvailable.
      Those guards are not enough to prevent any failure while attaching, so we're
      wrapping calls to `attachAndInitThread`/`_onThreadInitialized` in try/catch
      blocks to avoid test failures.
      Differential Revision: https://phabricator.services.mozilla.com/D88766
    • Nicolas Chevobbe's avatar
      Bug 1662054 - Add a destroy function to targetList. r=jdescottes, a=RyanVM · 1a982041
      Nicolas Chevobbe authored
      At the moment, we don't have any guards in the targetList to _not_ execute the
      creation/destruction listeners once the toolbox gets destroyed.
      We only have a stopListening function on the targetList that is called when we
      close the toolbox, but we can't rely only on that since it's also called when
      doing a target switch (and working around that is very racy).
      One solution would be to follow the common pattern we have everywhere by having
      a destroy method that we would check before trying to call the listeners callback.
      This might help with intermittent test failures.
      Differential Revision: https://phabricator.services.mozilla.com/D88765
  14. 07 Sep, 2020 1 commit
  15. 08 Sep, 2020 10 commits
  16. 07 Sep, 2020 3 commits