This test checked the implementation of cache_isolation by checking the
values of the hashing keys. This has been removed in favour of
privacy.partition.network_state (Bug 1590107)
Depends on D102715
Differential Revision: https://phabricator.services.mozilla.com/D103030
Currently when the GPU cache is resized we allocate a new texture and
then copy the contents of the old texture to the new texture. This
copy requires either EXT_copy_image (for glCopyImageSubData) or
EXT_color_buffer_float (to bind the RGBAF32 texture to a framebuffer).
On devices where neither extension is supported, don't attempt to copy
the old texture. Instead mark the entire CPU-side copy of the cache as
dirty, meaning we will subsequently upload the entire contents to the
new texture. (A complete CPU-side copy is only mainted for the
PixelBuffer gpu cache bus type, not for Scatter ones. However, as the
Scatter type also requires EXT_color_buffer_float, we will only be in
this situation for PixelBuffer buses.)
Differential Revision: https://phabricator.services.mozilla.com/D103071
Because DecideScrollableLayer uses the existence of a displayport in it's decision.
In practice though we only paint from process root documents and the root scroll frame will have a displayport (almost?) always. So it's a small correctness improvement that is likely to have little effect.
Differential Revision: https://phabricator.services.mozilla.com/D102588
This uses a similar approach to HasNameDependent, introducing a new HasDescriptionDependent.
However, we don't fire events on ancestors, since a description is never computed from an Accessible's own subtree without an explicit described by relation.
Differential Revision: https://phabricator.services.mozilla.com/D102678
HasNameDependent is now set on an Accessible (and thus its descendants) which has A LABEL_FOR relation.
When text mutations occur on such an Accessible, EventQueue::PushNameChange now queues a name change for the Accessible being labelled.
Differential Revision: https://phabricator.services.mozilla.com/D102677
`BaseCompilationStencil::isCompilationStencil() == true` means it's always
`CompilationStencil`, because initial stencil is always stored into
`CompilationStencil`.
However, `BaseCompilationStencil::isCompilationStencil() == false` doesn't
always mean it's not `CompilationStencil`, because while delazification
the delazification stencil is stored into `CompilationStencil`.
Differential Revision: https://phabricator.services.mozilla.com/D103019
This patch makes the following changes:
1. Don't call ReflowInput::CalculateBlockSideMargins() for nsTableFrame
so that setting nsTableFrame's computed margins to zero in
SizeComputationInput::InitOffsets() remains true. Also, add an assertion
in nsTableFrame::Reflow() to ensure that.
2. Remove useless nsTableFrameWrapper::GetChildMargin() because the
method is used to get nsTableFrame's margins, which are now all zero.
Also, the old code that subtracts the block-axis margin from available
block-size doesn't really make sense.
3. Pass all-zero innerMargins to nsTableWrapperFrame::SetDesiredSize(),
and use table wrapper's content-box inline-size as the final desired
border-box inline-size rather than reconstructing it from caption and
inner table's inline-size & margin like the old code.
This inline-size already takes inner table's intrinsic size and
caption's inline-size into consideration in
nsTableWrapperFrame::ComputeAutoSize(), and is the final inline-size we
want to use.
In the next part, we are going to simplify all nsTableWrapperFrame's
methods that take inner frame's margin.
Differential Revision: https://phabricator.services.mozilla.com/D103065
For a spread call like `foo(...args)`, if OptimizeSpreadCall succeeds, we don't hit a breakpoint associated with `...args`, because we skip past that code. Before the parent patch, this wasn't a problem in this testcase, because we were only generating OptimizeSpreadCall for rest parameters. After that patch, we are generating OptimizeSpreadCall more frequently.
We don't actually care about hitting this breakpoint, so I'm just updating the test.
Differential Revision: https://phabricator.services.mozilla.com/D101232
When OptimizeSpreadCall was introduced, we conservatively only emitted it when the spread argument was a rest parameter. At the time, OptimizeSpreadCall required a VM call. It has been rewritten to use an IC, making the failure case very efficient. If we do not emit OptimizeSpreadCall, then we must allocate and copy an array object, even if the argument is already a packed array. In a microbenchmark, emitting OptimizeSpreadCall for non-rest-parameter cases is more than a 2x speedup, and generating the OptimizeSpreadCall in a non-packed-array case is <5% slowdown. The optimized case is also likely to be much more common in real code.
This patch extends OptimizeSpreadCall to be emitted whenever the single spread argument is any Name node. In theory we might also want to allow other nodes, but currently the bytecode emitter will call emitTree on the first argument twice in this case, which is fine for a Name node but broke in testing for `foo(...function() {})` (because we tried emitting a non-hoisted function twice).
Differential Revision: https://phabricator.services.mozilla.com/D101231
Valentin Gosu
Jamie Nicol
Emilio Cobos Álvarez
Timothy Nikkel
Lee Salzman
James Teh
Tooru Fujisawa
Ting-Yu Lin
Matt Woodrow
Jeff Muizelaar
Bogdan Tara
Iain Ireland
Emily McDonough
Cosmin Sabou
Steve Fink
Andreu Botella
Sean Feng