1. 06 Jan, 2021 1 commit
  2. 14 Jan, 2021 4 commits
  3. 15 Jan, 2021 4 commits
  4. 14 Jan, 2021 3 commits
  5. 13 Jan, 2021 4 commits
  6. 08 Jan, 2021 1 commit
  7. 06 Jan, 2021 1 commit
  8. 12 Jan, 2021 1 commit
  9. 13 Jan, 2021 1 commit
  10. 12 Jan, 2021 1 commit
  11. 14 Jan, 2021 3 commits
  12. 06 Jan, 2021 1 commit
  13. 11 Jan, 2021 1 commit
    • Emilio Cobos Álvarez's avatar
      Bug 1683188 - CrossProcessPaint code shouldn't mess with tab state from the... · ad6fdeea
      Emilio Cobos Álvarez authored
      Bug 1683188 - CrossProcessPaint code shouldn't mess with tab state from the content process. r=mattwoodrow,NeilDeakin, a=jcristau
      
      There's JS running since we save the active status till we restore it,
      so arbitrary things can happen, including receiving an IPC message from
      the child saying that we're now really active.
      
      If then we restore the wrong (old) status, stuff gets confused and
      sadness ensues.
      
      Screenshotting background tabs seems to work without this so it's not
      clear to me why messing with the activeness state was necessary to begin
      with.
      
      Differential Revision: https://phabricator.services.mozilla.com/D101060
      ad6fdeea
  14. 08 Jan, 2021 1 commit
  15. 11 Jan, 2021 1 commit
  16. 14 Jan, 2021 2 commits
    • Mozilla Releng Treescript's avatar
      no bug - Bumping Firefox l10n changesets r=release a=l10n-bump · 0ade33fc
      Mozilla Releng Treescript authored
      be -> 521635b81a2cd635a7a85f36b3a6bc1f0dd71c52
      cs -> 7e0e6972d12ed8269f5c58c3b55b837d8afe7f95
      cy -> ad2e7075de5e328d37929cc7839f7de2e6688795
      da -> f806376c1b216267be7bf6b135107344d1fae569
      dsb -> bb27af18ad8854d242e3ba5ffba65bf12816a232
      es-AR -> 22c1e1d73dece24e1531725c49456f812ae6f69b
      es-MX -> 1a2efd67768e431812c8ac8fb48e66ee68b8b7d4
      fr -> 6ba53866725bdb1176a0134042156cad2b378536
      fy-NL -> c255ae1b9162df300452e16a725866fffcdfd520
      hsb -> 8b140e3f3f1412ae58f3edfc76223decc1d16fa9
      ia -> 4ba4eaf6c5e6c18138b18913ab44b04b375f14ec
      it -> 84d529c6c8c619d78317d9aa581052df09517181
      ja -> a25fdc68cc8702100ac27fb0b57bac58b8c0be1b
      ja-JP-mac -> b2d59bfd23451e471cbc02a9cc4c199daf8ced2f
      nl -> 30e3855f4fe035e50fb7a3596ee48c17ee533bb3
      oc -> e302413af0acc45a2c32a32445dcf6738999fb29
      tr -> 915e9c207473c6c2f4353eae809dcf89ae29ca27
      zh-TW -> de2fee3a071ece9bd9cb15db1673682b6ca8ff86
      0ade33fc
    • Julien Cristau's avatar
  17. 24 Dec, 2020 1 commit
  18. 14 Jan, 2021 1 commit
  19. 13 Jan, 2021 1 commit
  20. 12 Jan, 2021 2 commits
  21. 08 Jan, 2021 1 commit
  22. 09 Jan, 2021 1 commit
    • Jim Blandy's avatar
      Bug 1681610: Use thicker borders when faking rounded rectangles. r=gw, a=jcristau · c801a944
      Jim Blandy authored
      `DisplayListBuilder::PushRoundedRect`, used for unordered list bullets and the
      like, draws rounded rectangles as ordinary rectangles with rounded borders that
      have a radius of half the rectangle. Unfortunately, this leads to tiny white
      dots at the center of the bullet under some magnifications. I haven't diagnosed
      why - perhaps there's something somewhere that snaps borders outward.
      
      Increasing the thickness of the borders to (an impossible) 60% of the width of
      the rectangle makes the problem go away. If this kludge doesn't work, we could
      add a rectangle covering the center.
      
      Differential Revision: https://phabricator.services.mozilla.com/D100753
      c801a944
  23. 08 Jan, 2021 1 commit
  24. 23 Dec, 2020 1 commit
  25. 13 Jan, 2021 1 commit