This is simple typo when payload is nothing.
Also, we should add unit tests for this since we don't run mochitest in
dom/push/test. The mochitest requires mock's implementation, but we doesn't
have it.
Differential Revision: https://phabricator.services.mozilla.com/D107067
I assume nsIFrame::IsAbsolutelyPositioned()'s callers really want to
check whether a frame is a real abspos frame, not just check a frame has
a abspos style. This could potentially change the behavior, but I feel
its the right thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D106580
When `aElement` is a <table>, `styleFrame` is the inner table frame. It
has the abspos style, but not the `NS_FRAME_OUT_OF_FLOW bit`. The bit is
set on the table wrapper frame in the `frame` variable.
When determining whether the <table> is absolutely positioned, we should
check `frame` instead of `styleFrame`. Otherwise we'll break <table>
element's offsetParent property after applying Part 2.
Without this patch, running `./mach test dom/html/test/test_bug375003-1.html`
can generate the following exception.
dom/html/test/test_bug375003-1.html | uncaught exception -
TypeError: can't access property "id", p is null at
t3@http://mochi.test:8888/tests/dom/html/test/test_bug375003-1.html:39:3
Differential Revision: https://phabricator.services.mozilla.com/D106746
IsFontSizeInflationContainer() is a helper of nsIFrame::Init(). That is,
when it is called from a caller like
nsCSSFrameConstructor::CreateFloatingLetterFrame(), the
`NS_FRAME_OUT_OF_FLOW` bit is not set yet. There is also a hint at the
call site
https://searchfox.org/mozilla-central/rev/362676fcadac37f9f585141a244a9a640948794a/layout/generic/nsIFrame.cpp#770
To fix it, we need to change the condition to check only the
floating style.
layout/reftests/bidi/with-first-letter-2b.html is one of the testcases
that can trigger the following assertion without this patch.
###!!! ASSERTION: should not be container for font size inflation
Differential Revision: https://phabricator.services.mozilla.com/D106579
Since merging stencils is a read-only operation for the source delazification
stencil and we already have a borrowed stencil at caller, it is more
consistent with our conventions to pass a CompilationStencil& instead of an
ExtensibleCompilationStencil&.
Differential Revision: https://phabricator.services.mozilla.com/D107014
Also add XDRStencilEncoder for non-incremental case, and
cleanup XDRStencilDecoder.
StencilDelazificationSet and gcOutputForDelazification become unused,
and will be removed by later patches.
Differential Revision: https://phabricator.services.mozilla.com/D105154
Fix a bug that can occur when:
- Parent stacking context is considered redundant
- Parent stacking context has a transform
- Parent stacking context establishes a raster root
- Parent stacking context has a clip
- Child stacking context has a filter (or other feature requiring a surface)
In these cases, the clips would be incorrectly propagated to the
primitives inside the child stacking context, instead of applied
to the child stacking context surface itself. This can cause correctness
issues when raster roots are established, and potential performance
issues if raster roots are not established.
Differential Revision: https://phabricator.services.mozilla.com/D107024
`IsDMABufEnabled()` will call `Configure()` from which we will possibly call into the driver code in `nsGbmLib::CreateDevice()`.
In order to prevent from calling the driver code in RDD process which has been sandboxed, we should reorder those checks.
Differential Revision: https://phabricator.services.mozilla.com/D107086
This check was likely added to try and limit the types of tasks that can be
created with fission. However it doesn't make sense to be filtering tasks based
on the project during the transforms stage. Tasks filtered out here don't exist
at all, so it's not possible to even schedule them on try with --full. This
type of filtering should be left to the target tasks stage of generation.
As a side effect, this patch enables the following tasks on autoland:
> test-linux1804-64-qr/debug-mochitest-webgpu-fis-e10s
> test-linux1804-64-qr/opt-web-platform-tests-print-reftest-fis-e10s
> test-linux1804-64-qr/opt-web-platform-tests-reftest-fis-e10s-1
> test-linux1804-64-qr/opt-web-platform-tests-reftest-fis-e10s-2
> test-linux1804-64-qr/opt-web-platform-tests-reftest-fis-e10s-3
> test-linux1804-64-qr/opt-web-platform-tests-reftest-fis-e10s-4
> test-linux1804-64-qr/opt-web-platform-tests-reftest-fis-e10s-5
> test-linux1804-64-qr/opt-web-platform-tests-reftest-fis-e10s-6
> test-linux1804-64/opt-marionette-fis-e10s
> test-linux1804-64/opt-marionette-headless-fis-e10s
> test-windows10-64-qr/opt-web-platform-tests-print-reftest-fis-e10s
> test-windows10-64-qr/opt-web-platform-tests-reftest-fis-e10s-1
> test-windows10-64-qr/opt-web-platform-tests-reftest-fis-e10s-2
> test-windows10-64-qr/opt-web-platform-tests-reftest-fis-e10s-3
> test-windows10-64-qr/opt-web-platform-tests-reftest-fis-e10s-4
> test-windows10-64/opt-marionette-fis-e10s
And the following tasks on central:
> test-linux1804-64-qr/debug-mochitest-webgpu-fis-e10s
> test-linux1804-64/debug-mochitest-webgpu-fis-e10s
While this change would ideally happen in a separate commit, fission team
indicated it was desirable to enable these tasks anyway, so I decided not
to spend effort disabling them here, only to enable them again later.
Depends on D107113
Differential Revision: https://phabricator.services.mozilla.com/D107114
This task gets enabled as a side effect of the last patch in this stack. This
patch preserves the status quo.
Depends on D107112
Differential Revision: https://phabricator.services.mozilla.com/D107113
These -profiling tasks are not currently running on fission. But the last patch in this stack
enables them as a side effect. This patch preserves the status quo.
Depends on D107107
Differential Revision: https://phabricator.services.mozilla.com/D107112
All the other browsertime tasks ignore non-shippable platforms except for this
one. It was causing problems for a later patch in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D107107
This patch ships Software WebRender to release to a small set (< 10%) of
Linux users whom we are unlikely to ever ship WebRender to. This
compromises of llvmpipe users with small screens and AVX2 support, and
NVIDIA binary driver users with small screens, AVX2 support and a driver
older than 460.32.3.
All of these users would be getting Software WebRender today in nightly
and early beta.
Differential Revision: https://phabricator.services.mozilla.com/D107118