Skip to content
Snippets Groups Projects
  1. Jul 27, 2024
    • Kelsey Gilbert's avatar
      Bug 1885245 - Remove PlainOldDataSerializer. r=mccr8 a=RyanVM · 2b8bf0f7
      Kelsey Gilbert authored
      There's no sufficiently robust way to identify POD types in C++, such
      that we could rely on this kind of thing for serialization.
      
      As one example, `bool` must be carefully handled on deserialize, in case
      an attacker wants to exploit the UB of bool with value 2.
      Additionally, generally it's not viable to tell whether all the members
      of a struct are PODs as well, and we need that level of assurance
      recursively!
      
      So we instead lean on e.g. ParamTraits_TiedFields/_IsEnumCase for our
      extreme robustness requirements.
      
      Differential Revision: https://phabricator.services.mozilla.com/D217518
      2b8bf0f7
  2. Jul 24, 2024
  3. Jun 20, 2024
  4. Jun 07, 2024
  5. Jun 06, 2024
  6. Jun 05, 2024
    • Dana Keeler's avatar
      Bug 1900132 - streamline PVerifySSLServerCert protocol r=jschanck · 77706690
      Dana Keeler authored
      Previously the PVerifySSLServerCert protocol consisted of two functions: one to
      call when certificate verification succeeded, and another to call upon failure.
      This was unnecessary, as the code before and after this protocol didn't have
      the same split. This patch unifies the protocol to better match the surrounding
      code. It also takes the opportunity to make use of some IPC helpers to
      serialize enums rather than manually casting to and from basic integer types.
      
      Differential Revision: https://phabricator.services.mozilla.com/D212594
      77706690
  7. May 30, 2024
    • Otto Länd's avatar
      Bug 1884221, 1895375: apply code formatting via Lando · ee23dcd8
      Otto Länd authored
      # ignore-this-changeset
      ee23dcd8
    • Ray Kraesig's avatar
      Bug 1895375 - [4/4] Propagate ipc::LaunchErrors to callers r=ipc-reviewers,nika · fce1a861
      Ray Kraesig authored
      * Adjust UtilityProcess{Host,Manager} to propagate ipc::LaunchErrors for
        their clients, or to create new ones where none previously existed.
      
      * Adjust the various clients of the above to to handle the additional
        information -- mostly by adding the additional failure-location data
        to log messages.
      
      * Fix an unrelated bug wherein the return type of `LaunchProcess` was
        declared as exclusive, despite being cached and reused.
      
      In particular, filedialog::Error objects should now contain -- and report
      to telemetry without further adjustment -- the actual error code from
      `ipc::LaunchError`s.
      
      (Reporting the original failure location as well will occur in bug
      1884221.)
      
      Differential Revision: https://phabricator.services.mozilla.com/D209715
      fce1a861
    • Ray Kraesig's avatar
      Bug 1895375 - [1/4] Adjust types associated with ipc::LaunchError ... · f6411a23
      Ray Kraesig authored
      Bug 1895375 - [1/4] Adjust types associated with ipc::LaunchError  r=ipc-reviewers,win-reviewers,gstoll,nika
      
      As the intended use for LaunchError::mFunction is telemetry, avoid the
      possibility of accidental exfiltration of PII by requiring that
      LaunchError be constructed from `StaticString`.
      
      Additionally, remove the Windows-specific constructor overloads in favor
      of an explicit factory function, and explicitly document that `mError`
      is a generic bag of bits rather than any kind of strict error type.
      
      No functional changes.
      
      Differential Revision: https://phabricator.services.mozilla.com/D209712
      f6411a23
  8. May 29, 2024
  9. May 28, 2024
  10. May 27, 2024
  11. May 24, 2024
  12. May 21, 2024
  13. May 17, 2024
  14. May 15, 2024
  15. May 14, 2024
    • Jamie Nicol's avatar
      Bug 1880503 - Generate paired minidump when GPU process is killed following... · 0056a7ee
      Jamie Nicol authored
      Bug 1880503 - Generate paired minidump when GPU process is killed following IPC timeout. r=aosmond,gsvelto
      
      When sync IPC under the top-level PCompositorManager protocol does not
      reply within a certain time threshold we purposefully kill the GPU
      process. While this allows the user to recover from a stuck GPU
      process, we have little visibility about the underlying cause.
      
      This patch makes it so that we generate a paired minidump for the GPU
      and parent processes prior to killing the GPU process in
      GPUProcessHost::KillHard(). The implementation roughly follows the
      equivalent for content processes in ContentParent::KillHard().
      
      As the GPU process can be purposefully killed during normal operation,
      and because generating minidumps can be expensive, we are careful to
      only do so when the new argument aGenerateMinidump is true. We
      additionally remove the aReason argument as it is unused (and
      currently innacurate in some places).
      
      As these minidumps may not automatically submitted we limit the
      minidumps generation to twice per session in order to avoid
      accumulating a large number of unsubmitted minidumps on disk.
      
      Differential Revision: https://phabricator.services.mozilla.com/D202166
      0056a7ee
  16. May 13, 2024
    • Stanca Serban's avatar
      Backed out 3 changesets (bug 1880503) for causing build bustages in nsCOMPtr.h. CLOSED TREE · ad459e5c
      Stanca Serban authored
      Backed out changeset 437063345a7b (bug 1880503)
      Backed out changeset 9665aa5e821d (bug 1880503)
      Backed out changeset 44d08ce97ae6 (bug 1880503)
      ad459e5c
    • Jamie Nicol's avatar
      Bug 1880503 - Generate paired minidump when GPU process is killed following... · 6e07140f
      Jamie Nicol authored
      Bug 1880503 - Generate paired minidump when GPU process is killed following IPC timeout. r=aosmond,gsvelto
      
      When sync IPC under the top-level PCompositorManager protocol does not
      reply within a certain time threshold we purposefully kill the GPU
      process. While this allows the user to recover from a stuck GPU
      process, we have little visibility about the underlying cause.
      
      This patch makes it so that we generate a paired minidump for the GPU
      and parent processes prior to killing the GPU process in
      GPUProcessHost::KillHard(). The implementation roughly follows the
      equivalent for content processes in ContentParent::KillHard().
      
      As the GPU process can be purposefully killed during normal operation,
      and because generating minidumps can be expensive, we are careful to
      only do so when the new argument aGenerateMinidump is true. We
      additionally remove the aReason argument as it is unused (and
      currently innacurate in some places).
      
      As these minidumps may not automatically submitted we limit the
      minidumps generation to twice per session in order to avoid
      accumulating a large number of unsubmitted minidumps on disk.
      
      Differential Revision: https://phabricator.services.mozilla.com/D202166
      6e07140f
    • Jon Coppeard's avatar
      Bug 1895661 - Part 1: Move GC zeal functions to JS namespace and add separate... · e38e561b
      Jon Coppeard authored
      Bug 1895661 - Part 1: Move GC zeal functions to JS namespace and add separate constants for browser and shell frequency r=sfink
      
      Sensible defaults are very different for the browser and the shell so I added
      separate constants. I think the JS testing functions can get called from the
      browser and so may pick the wrong default but it's not too serious.
      
      Differential Revision: https://phabricator.services.mozilla.com/D210058
      e38e561b
  17. May 08, 2024
  18. May 06, 2024
  19. May 03, 2024
  20. May 02, 2024
  21. Apr 30, 2024
Loading