Product nodes are eagerly resolved during parse time, but sum nodes are
not. This might cause floating point inprecision in sum nodes, which
leads to invalid calculations, e.g. `round(down, (7 - 1) / 3, 1)` would
end up being `round(down, (2.3333333 - 0.33333334), 1)`, then
`round(down, 1.99999996, 1)`, which equals `1`, which is incorrect.
Original Revision: https://phabricator.services.mozilla.com/D225936
Differential Revision: https://phabricator.services.mozilla.com/D232498
Signed-off-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Filipe Laíns <lains@riseup.net>
Differential Revision: https://phabricator.services.mozilla.com/D231480
To avoid iterators being invalidated during iteration, this needs a collection
that allows mutation during iteration (like std::set) or a copy. This uses
a copy to get the best asymptotic performance.
Includes a test that both OnChange and OnError allow listener removal.
Original Revision: https://phabricator.services.mozilla.com/D231002
Differential Revision: https://phabricator.services.mozilla.com/D232097
This restores behavior from before bug 1835864, effectively.
The top level image document's root element has transparent background.
Before that patch, we used to blend that with
GetDefaultBackgroundColorDraw(), which was white.
This should generally not change behavior, because the page frame itself
is white, but it does on PrintTargetWindows (probably a cairo bug?),
where it causes our page content clip not to apply.
In any case, restoring behavior here is trivial, so let's do that for
now, I'll file a follow-up bug for the underlying issue.
Differential Revision: https://phabricator.services.mozilla.com/D228514
We have found that some users are unable to download the GMP plugin from
the default URL because of their specific network
configuration/circumstances. For example, some users cannot access the
*.gvt1.com domain. This patch adds the ability for balrog to supply
alternative mirror URLs to attempt to download the plugin, where we first
try the primary, and if supplied any secondaries, in the given order.
Original Revision: https://phabricator.services.mozilla.com/D229690
Differential Revision: https://phabricator.services.mozilla.com/D230617
The auto-bootstrap code gracefully handles the lack of information as to
what toolchains are available in spidermonkey standalone trees, but the
fallback code path for when toolchains are not to be unpacked doesn't
handle the situation.
By making the toolchains themselves define whether they are to be
unpacked, we can remove the fallback code path and use auto-bootstrap in
all cases.
This makes `mach artifact toolchain --from-build` stop requiring a
manual `--no-unpack`, but `--from-task` still needs it because it
can't infer that information, as it doesn't have the task graph.
Original Revision: https://phabricator.services.mozilla.com/D231342
Differential Revision: https://phabricator.services.mozilla.com/D231846
Upstream changes have changed the config path of depot_tools to default
to `$HOME/.config`. Instead we also have the option to set
`$XDG_CONFIG_HOME`. At the moment this only affects linux, with
windows/macos slated to have a similar change soon with possibly
different setup.
As far as I can tell, this problem occurs regardless of what is
in the PRIORITY_UPDATE frames. I suspect the connection gets closed by
the server because it's receiving a lot of HTTP/2 frames it does not
understand, and treats these as a DoS attack.
I've also tried to convince Chrome to generate a PRIORITY_UPDATE frame
but I was unsuccessful.
My suggestion is to disable sending PRIORITY_UPDATE for now.
Original Revision: https://phabricator.services.mozilla.com/D230929
Differential Revision: https://phabricator.services.mozilla.com/D231071
