Skip to content
Snippets Groups Projects
  1. Jan 18, 2024
  2. Jan 05, 2024
    • Andrew Osmond's avatar
      Bug 1868737 - Allow minimal gfx features by default for uncertain... · c89b8da4
      Andrew Osmond authored
      Bug 1868737 - Allow minimal gfx features by default for uncertain configurations. r=jrmuizel,perftest-reviewers,kshampur a=RyanVM
      
      Some features such as the GPU process (except on Android), backdrop
      filter (because it always works with Software WebRender), ANGLE (because
      it is generally good) and out of process WebGL (we generally want to
      remote WebGL for sandboxing purposes) are special, and should not be
      disabled simply because we are uncertain about our configuration. In
      these situations, disable most features, but keep these enabled by
      default.
      c89b8da4
  3. Dec 15, 2023
  4. Jan 04, 2024
    • Ting-Yu Lin's avatar
      Bug 1867784 - Force reflow all kids in the last column balancing reflow. a=RyanVM · 1b68cef8
      Ting-Yu Lin authored
      The bug occurs because some abspos children are split, but not being reflowed
      again in the last column balancing reflow where the available block-size of the
      last column might be unconstrained.
      
      This patch makes the callers utilizing `ReflowInput::ShouldReflowAllKids()`
      always reflow in the last column balancing reflow to ensure the correctness of
      the layout.
      
      Note: the `mIsInLastColumnBalancingReflow` flag is inheriting from parent to
      child reflow input, but it will stop at the nested `nsColumnSetFrame` because
      the nested one will create its own `ReflowConfig::mIsLastBalancingReflow` and
      assign that flag when creating the reflow input for the children.
      1b68cef8
  5. Oct 22, 2023
  6. Jun 29, 2023
  7. Jul 25, 2023
  8. Oct 13, 2023
  9. Jan 15, 2024
  10. Feb 08, 2024
  11. Feb 02, 2024
    • Lee Salzman's avatar
      Bug 1878182 - Instantiate Cairo scaled font for... · 7647aac1
      Lee Salzman authored
      Bug 1878182 - Instantiate Cairo scaled font for ScaledFontBase::GetPathForGlyphs. r=jfkthameApproved for 123 beta 8, thanks. a=pascalc
      
      This bug likely dates back to bug 1584268, which makes it so that Cairo scaled fonts must be
      instantiated on demand for their first use. It seems like some StrokeGlyphs machinery got
      overlooked and somehow never caused a problem till now.
      
      Differential Revision: https://phabricator.services.mozilla.com/D200472
      7647aac1
  12. Jan 24, 2024
  13. Feb 06, 2024
  14. Jan 11, 2024
  15. Dec 27, 2023
  16. Feb 05, 2024
  17. Feb 06, 2024
  18. Jan 15, 2024
  19. Jan 29, 2024
  20. Feb 06, 2024
  21. Feb 05, 2024
    • Sebastian Hengst's avatar
      Bug 1874627 - regenerate expiring test certificates for 2024 (branch patch),... · a9239f3e
      Sebastian Hengst authored
      Bug 1874627 - regenerate expiring test certificates for 2024 (branch patch), this time with certificates included. r=jschank a=test-only
      
      
      * the certificates were regenerated using `./mach generate-test-certs`
      * the build/pgo/certs/ changes were made using
        `./mach python build/pgo/genpgocert.py`
      * the zip files in security/manager/ssl/tests/unit/test_signed_apps/ were
        updated per the directions in the corresponding moz.build file
      * security/manager/ssl/tests/unit/test_cert_override_read.js needed manual
        updating
      
      These certificates and other test artifacts will now expire in 2025.
      
      Differential Revision: https://phabricator.services.mozilla.com/D199156
      a9239f3e
  22. Jan 20, 2024
  23. Feb 05, 2024
  24. Jan 29, 2024
    • Daniel Holbert's avatar
      Bug 1867886: Ensure that NotificationController can't re-register with the... · f3c2f7c3
      Daniel Holbert authored
      Bug 1867886: Ensure that NotificationController can't re-register with the refresh driver after it's been unregistered in Shutdown.  a=pascalc
      
      This is just a "belt-and-suspenders" invariant tightening.  Shouldn't impact
      behavior at all, assuming that we don't call methods on NotificationController
      objects that have been nerfed with Shutdown().
      
      Original Revision: https://phabricator.services.mozilla.com/D195321
      
      Differential Revision: https://phabricator.services.mozilla.com/D199400
      f3c2f7c3
    • Daniel Holbert's avatar
      Bug 1867358 part 4: Add some release asserts (and upgrade an existing assert),... · 1ded75c5
      Daniel Holbert authored
      Bug 1867358 part 4: Add some release asserts (and upgrade an existing assert), to validate that NotificationController isn't still registered as a refresh observer when it's destroyed.  a=pascalc
      
      If these assertions somehow fail, then we are probably doomed to crash anyway.
      The new release assertions just make it so we'll crash in a controlled way,
      with a more actionable backtrace, closer to the problem-spot.
      
      This patch also removes one mDocument null-check that's becoming redundant
      since it follows a release-assert that would make us abort if the pointer is
      null.
      
      Original Revision: https://phabricator.services.mozilla.com/D195042
      
      Differential Revision: https://phabricator.services.mozilla.com/D199399
      1ded75c5
    • Daniel Holbert's avatar
      Bug 1867358 part 3: Adjust NotificationController to avoid modifying... · e3609aab
      Daniel Holbert authored
      Bug 1867358 part 3: Adjust NotificationController to avoid modifying mObservingState after Shutdown has been called.  a=pascalc
      
      We can sometimes reach the code that this patch is touching, just we've been
      shutdown (as can be seen by the fact that we have a null mDocument pointer); in
      that case, it's problematic for us to be assigning 'mObservingState' here. The
      mObservingState assignment is meant to be *undoing* the temporary assignments
      earlier in the function, but in this post-Shutdown situation, it's actually
      causing us to forget that we already unregistered as a refresh observer, in a
      nested stack level's call to Shutdown().
      
      I think this one place is the only mObservingState assignment that's got this
      problem. The other mObservingState assignments should all be OK (they don't
      need a "have we shut down" check), because they're all either:
      a) modifying mObservingState to record an actual change that we just made to
      our RefreshDriver registration,
      ...or:
      b) immediately adjacent to code that dereferences mDocument, implying that
      mDocument is known-to-be-non-null at that point, which means we know we haven't
      been Shutdown.
      
      This patch unblocks us from adding a release assert in the
      NotificationController destructor in the next patch in this series. (Without
      this patch, that assertion can be made to fail, via this inadvertent
      mObservingState assignment.)
      
      
      Original Revision: https://phabricator.services.mozilla.com/D195200
      
      Differential Revision: https://phabricator.services.mozilla.com/D199398
      e3609aab
Loading