Skip to content
Snippets Groups Projects
  1. Jul 29, 2024
  2. Jul 26, 2024
  3. Jul 25, 2024
  4. Jul 27, 2024
  5. Jul 26, 2024
  6. Jul 24, 2024
  7. Jul 23, 2024
  8. Jul 22, 2024
  9. Jul 25, 2024
  10. Jul 24, 2024
  11. Jul 19, 2024
  12. Jul 03, 2024
    • Jan Varga's avatar
      Bug 1906083 - Add a bool template argument to TypedArray::ProcessData to... · 2f5cfb66
      Jan Varga authored
      Bug 1906083 - Add a bool template argument to TypedArray::ProcessData to enable support for large types arrays; r=peterv, a=dmeehan
      
      Currently, there isn't a straightforward and safe method to verify the length
      before invoking TypedArray::ProcessData. If the length isn't checked and
      exceeds INT32_MAX, it triggers a release assert. The addition of the
      AllowLargeTypedArrays argument offers a mechanism to validate the length within
      the processor, allowing for an error to be returned if necessary.
      
      Differential Revision: https://phabricator.services.mozilla.com/D215478
      2f5cfb66
  13. Jul 24, 2024
  14. Jul 22, 2024
  15. Jul 19, 2024
  16. Jul 23, 2024
  17. Jul 19, 2024
    • Masayuki Nakano's avatar
      Bug 1897255 - Make `nsIFrame::PeekOffsetForLine` won't cross editing host... · 022eb9e9
      Masayuki Nakano authored
      Bug 1897255 - Make `nsIFrame::PeekOffsetForLine` won't cross editing host boundary unless the callers allows that r=emilio, a=dmeehan
      
      The problems in the testcase are, `nsIFrame::PeekOffsetForLine` returns a frame
      for any content node outside the editing host and `nsIFrame::GetLastLeaf`
      returns a native anonymous subtree node if the frame is for the native
      anonymous subtree root like `<input>` or `<textarea>`.
      
      For fixing the former, the methods need to check whether found frame's editable
      state **and** whether the editable node is an inclusive descendant of the
      editing host.  However, there are complicated cases with inline editing hosts
      and elements whose `contenteditable` is set to `false` and this is a new
      regression for ESR 128.  Therefore, we need to fix this without any behavior
      changes as far as possible.  Therefore, this patch basically checks only whether
      the editing state of found one is editable and/or whether the one is an
      inclusive descendant of the editing host to avoid `Selection` moves outside the
      editing host.  The reaming complicated cases should be handled in new bugs which
      blocks bug 1873155.
      
      For fixing the latter, `nsIFrame::GetLastLeaf` needs to check the given frame's
      content is a native anonymous subtree root or not.
      
      Differential Revision: https://phabricator.services.mozilla.com/D216371
      022eb9e9
  18. Jul 18, 2024
  19. Jul 19, 2024
    • Nika Layzell's avatar
      Bug 1834864 - Select BCG more consistently during COOP+COEP process switches,... · 07eb80a5
      Nika Layzell authored
      Bug 1834864 - Select BCG more consistently during COOP+COEP process switches, r=smaug,tabbrowser-reviewers,mak, a=dmeehan
      
      Previously it was possible to bypass specific BCG selection based on
      cross-origin isolated status if the site was allowed to load file URIs
      using enterprise policies, which could lead to a crash.
      
      This patch changes the behaviour such that BCG selection now happens
      correctly. The site will still not be cross-origin isolated due to being
      loaded into a file content process.
      
      Differential Revision: https://phabricator.services.mozilla.com/D217007
      07eb80a5
  20. Jul 12, 2024
    • Jon Coppeard's avatar
      Bug 1871303 - Ensure there is no more marking at the start of sweeping r=sfink, a=dmeehan · 95210036
      Jon Coppeard authored
      There are two issues here. The first is that there unexpected marking work at
      the start of sweeping after entering from the mark phase without yielding. We
      previously called assertNoMarkingWork() after markUntilBudgetExhausted() in the
      marking phase so something since then must have added it.
      
      As far as I can tell this must be the conditional call to
      collectNurseryFromMajorGC(), where a post barrier for a pointer cleared during
      finalization (e.g. for Maps in mapObject::sweepAfterMinorGC) ends up marking
      something. I'm not sure such barriers are necessary, but for now the safest
      thing to do is to move this nursery collection to the start of the slice so
      that it happens before we drain the mark stack.
      
      The second issue is that we check the budget and conditionally yield if we
      enter from the marking state. The comment above this code states that this is
      not safe since we have not yet started sweeping a sweep group. This check was
      added in bug 1865383 but was not the main part of the fix. I think we should
      remove this.
      
      I wasn't able to come up with a test case to reproduce this.
      
      Differential Revision: https://phabricator.services.mozilla.com/D215925
      95210036
  21. Jul 23, 2024
  22. Jul 22, 2024
  23. Jul 15, 2024
  24. Jul 18, 2024
  25. Jul 17, 2024
  26. Jul 04, 2024
Loading