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
The nesting level is tracked on the storage connection. The thread safety is
ensured by holding a lock while a transaction is being started/commited/rolled
back. For these purposes, the sharedDBMutex has been exposed on
mozIStorageConnection interface and additional helper methods have been added
to the interface as well.
Differential Revision: https://phabricator.services.mozilla.com/D106019
Finally, use the primitives from the previous change to deliver gamepad changes.
If the shared memory shortcut is available, all gamepad changes will be
delivered over it. When the children receive the signal, they will diff their
last-known state against the new state and generate events to update JS.
Differential Revision: https://phabricator.services.mozilla.com/D105129
Add the scaffolding to setup the shared memory GamepadState between the
GamepadPlatformService and GamepadManager. The next changeset will actually
integrate the new broadcast infrastructure into the gamepad code.
Differential Revision: https://phabricator.services.mozilla.com/D105128
