1. 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
  2. 09 Jun, 2020 1 commit
  3. 12 Jun, 2020 1 commit
  4. 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
  5. 15 Jun, 2020 9 commits
  6. 13 Jun, 2020 1 commit
    • Mozilla Releng Treescript's avatar
      no bug - Bumping Firefox l10n changesets r=release a=l10n-bump DONTBUILD · bb31abe0
      Mozilla Releng Treescript authored
      da -> fe34708da1f6
      el -> 547623e506fc
      en-GB -> 2872f66387a4
      es-CL -> 61fa6faa9f3c
      fi -> 32a8f322c911
      hr -> 1974e95a89c3
      ia -> 4fe9f8c2ed69
      it -> fa6ada06c5ca
      ja -> 9780baceeb10
      ja-JP-mac -> 102131a8cd84
      kab -> c20dc19f1e3e
      ko -> 990a116858a6
      nb-NO -> 960f600627bd
      nn-NO -> 82647fce2a00
      pt-BR -> 986d40be20dd
      pt-PT -> ccf1b9f4f152
      rm -> 0f4d77f43b1d
      sq -> 22786cc6eb3f
      bb31abe0
  7. 12 Jun, 2020 1 commit
    • Mozilla Releng Treescript's avatar
      no bug - Bumping Firefox l10n changesets r=release a=l10n-bump DONTBUILD · 3d613eae
      Mozilla Releng Treescript authored
      be -> e2665198c9c3
      ca -> 2c0274f57711
      da -> 98ebce9f28e9
      el -> b87b209a6780
      es-AR -> 6e73529cca68
      fi -> 15bf51260278
      fr -> c4122b9ef40e
      gn -> bab5df2602cf
      hsb -> bb813d7774a3
      it -> ed49aa63b129
      kab -> 366265803f7a
      km -> be16a68f0511
      nb-NO -> 45ac1da33d77
      nn-NO -> b87b2baa1ea0
      oc -> 240d3b54943b
      pl -> c165d6c8d537
      pt-BR -> c927852d340a
      rm -> e30250d2c493
      sl -> de18a4c1e178
      sq -> 76866b7fcb4e
      tr -> 9ccf3a7328ef
      ur -> f0243cbf47c3
      zh-CN -> 00640e50217f
      3d613eae
  8. 08 Jun, 2020 1 commit
  9. 05 Jun, 2020 1 commit
  10. 11 Jun, 2020 1 commit
  11. 10 Jun, 2020 1 commit
  12. 09 Jun, 2020 1 commit
  13. 05 Jun, 2020 5 commits
  14. 09 Jun, 2020 1 commit
  15. 10 Jun, 2020 1 commit
  16. 09 Jun, 2020 1 commit
  17. 12 Jun, 2020 6 commits
  18. 08 Jun, 2020 1 commit
  19. 11 Jun, 2020 3 commits
  20. 01 Jun, 2020 1 commit
  21. 08 Jun, 2020 1 commit