Skip to content
GitLab
Switch branch/tag
  1. 13 Jun, 2020 3 commits
  3. 16 Jun, 2020 5 commits
  5. 02 Jun, 2020 1 commit
  7. 15 Jun, 2020 1 commit
  9. 10 Jun, 2020 1 commit
  11. 02 Jun, 2020 1 commit
  13. 01 Jun, 2020 1 commit
  15. 27 May, 2020 1 commit
  17. 09 Jun, 2020 1 commit
  19. 15 Jun, 2020 1 commit
  21. 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
  23. 15 Jun, 2020 2 commits
  25. 11 Jun, 2020 1 commit
  27. 10 Jun, 2020 1 commit
  29. 09 Jun, 2020 2 commits
  31. 10 Jun, 2020 2 commits
  33. 13 Jun, 2020 1 commit
  35. 12 Jun, 2020 2 commits
  37. 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
  39. 09 Jun, 2020 1 commit
  41. 12 Jun, 2020 1 commit
  43. 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
  45. 15 Jun, 2020 8 commits