1. 13 Jun, 2020 2 commits
  2. 16 Jun, 2020 5 commits
  3. 02 Jun, 2020 1 commit
  4. 15 Jun, 2020 1 commit
  5. 10 Jun, 2020 1 commit
  6. 02 Jun, 2020 1 commit
  7. 01 Jun, 2020 1 commit
  8. 27 May, 2020 1 commit
  9. 09 Jun, 2020 1 commit
  10. 15 Jun, 2020 1 commit
  11. 16 Jun, 2020 1 commit
    • Mozilla Releng Treescript's avatar
      no bug - Bumping Firefox l10n changesets r=release a=l10n-bump DONTBUILD · 6250ea0e
      Mozilla Releng Treescript authored
      be -> 13899cdb400e
      de -> 1026e4b5724e
      el -> 05bac7055f68
      en-GB -> 1789c49d6a47
      eo -> 7372329185d3
      es-AR -> b07bf75f6377
      es-CL -> a2d4f149eba4
      eu -> dd460cbff693
      fy-NL -> 4407f6501899
      hu -> 93e9cc73e955
      ia -> 569fbfe91248
      id -> 59863738339c
      kab -> 105e5e7a03ca
      kk -> d263959f877f
      nb-NO -> 16a66e879417
      nl -> ff6078752ba0
      nn-NO -> 17bdac759488
      pt-BR -> 606720ea65b5
      rm -> 0d276c4c87b7
      sl -> ed09aee32757
      sq -> 25523b0ec6c9
      sr -> 8c299723866e
      sv-SE -> 9d93412954a2
      tr -> d7351874250a
      uk -> 7ee557d6dde8
      ur -> 1d4f1d37b58c
      6250ea0e
  12. 15 Jun, 2020 2 commits
  13. 11 Jun, 2020 1 commit
  14. 10 Jun, 2020 1 commit
  15. 09 Jun, 2020 2 commits
  16. 10 Jun, 2020 2 commits
  17. 13 Jun, 2020 1 commit
  18. 12 Jun, 2020 2 commits
  19. 10 Jun, 2020 1 commit
    • Emilio Cobos Álvarez's avatar
      Bug 1644264 - Mark frame with text-overflow ellipsis as modified when overflow... · 5c4e04d4
      Emilio Cobos Álvarez authored
      Bug 1644264 - Mark frame with text-overflow ellipsis as modified when overflow changes. r=mattwoodrow, a=jcristau
      
      This prevents us not descending to rebuild the display list if the
      overflow changes during an intermediate layout like a flex layout.
      
      To capture Matrix discussion: This is a bit unfortunate, but the idea is
      that text-overflow is usually pretty small (at most one line of content)
      so we can probably live with this.
      
      An alternative would be to do something like
      nsDisplayListBuilder::MarkFrameForDisplayIfVisible, which could work as
      well.
      
      Note that this is a bit of a speculative fix because neither me or
      Cameron have been able to reproduce the issue in local builds (I tried
      all the combinations of gfx-things that I could think about). :-(
      
      If this doesn't fix it on next nightly, we should back out and try to
      repro some other way, I guess. But the hypothesis of why it happens
      makes sense to me, and if it's correct it should fix the issue.
      
      Differential Revision: https://phabricator.services.mozilla.com/D79009
      5c4e04d4
  20. 09 Jun, 2020 1 commit
  21. 12 Jun, 2020 1 commit
  22. 09 Jun, 2020 1 commit
    • valenting's avatar
      Bug 1640724 - [beta] head_trr.js: Emit DoH response when we got all the bytes... · 2ea6a70b
      valenting authored
      Bug 1640724 - [beta] head_trr.js: Emit DoH response when we got all the bytes instead of "end" event. r=dragana, a=test-only
      
      
      This patch is a workaround for an issue that causes an intermittent failure
      in test_trr_case_sensitivity.js.
      I was able to reproduce the bug locally with some logging, but not with
      nsHttp:5 or under rr, which made it difficult to diagnose the root cause.
      What I was able to determine using logging and timestamps in the nodejs code
      is that we would not get the "end" event for a request, to which we were
      reacting to send back the DoH response. The request has a timer, and
      eventually that timer would fire and cancel the request. At that point
      we would see the "end" event in nodejs but it's too late to actually process
      the response.
      
      It's not clear if this was a bug in Firefox's HTTP2 implementation
      (maybe the end isn't signaled properly) or in nodejs.
      
      This fix makes it so we send back the response when the number of bytes
      specified in contentLength reaches the server.
      We should investigate in a follow-up bug if there's another Necko bug
      involved here.
      
      Differential Revision: https://phabricator.services.mozilla.com/D79542
      2ea6a70b
  23. 15 Jun, 2020 9 commits