The recursive call is not safe. We should do it more carefully. For now,
we should not hide the recursive call into the leaf handler.
Differential Revision: https://phabricator.services.mozilla.com/D85573
This patch:
- Creates an anon-box pseudo-style for PrintedSheetFrame, in part so that it
can co-opt the styles that we formerly gave to page-frames in ua.css, to draw
the sheet of paper and the shadow in Print Preview.
- Adjusts nsCSSFrameConstructor to create a PrintedSheetFrame as the parent of
nsPageFrame (inserting between it and its nsPageSequenceFrame container, in
the frame tree).
- Fleshes out out a simple BuildDisplayList() implementation for
PrintedSheetFrame (taking the responsibility for "paper"-drawing from
nsPageFrame).
- Fleshes out a simple Reflow implementation for PrintedSheetFrame, just
placing the child page (assuming there's only one for now) at the origin.
- Adjusts nsPageFrame and nsPageSequenceFrame to account for the fact that
there's another layer between them now.
Note that PrintedSheetFrame needs to implement AppendDirectlyOwnedAnonBoxes()
(just as nsSimplePageSequence and nsPageFrame do), since it owns anonymous
nsPageFrame instances. This implementation only needs to append the first
child, as explained in the code-comment and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1374761#c9 (and of course, for
now, PrintedSheetFrame only has one child at a time anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D83457
This patch is just to get the "new file/frame class" boilerplate out of the
way. As of this patch, this frame class *is* compiled, but it doesn't do
anything and it's never instantiated. The next patch in this series will make
us actually start using it at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D83456
I believe this is correct for blending a non-premuliplied source into a premultiplied destination. Only the source color part should be different to normal blending, since it needs to be multiplied by the source alpha channel.
Differential Revision: https://phabricator.services.mozilla.com/D85716
Replace the enclosing scope field with a Maybe<ScopeIndex> field. When the
enclosing scope is an existing concrete scope, the CompilationInfo data will
be used instead.
One source of complexity is that scripts in the self-hosting global use the
existing empty global scope and indicate this with a placeholder type in the
gc-things array. In this case there is no ScopeCreationData and we return
mozilla::Nothing for the scopeIndex. When ScopeCreationData::enclosing
computes the actual scope, it handles this case.
Differential Revision: https://phabricator.services.mozilla.com/D84889
Replace the EnvironmentShapeCreationData variant with a Maybe<uint32>
numEnvironmentSlots field. Nothing value here indicates no environment shape
is used, and the empty environment case is identified by numEnvironmentSlots
being 0. The firstFrameSlot value is also saved in order to recreate the
BindingIter during stencil instantiation.
Also simplify the `updateEnvShapeIfRequired` methods by using the
BASESHAPE_FLAGS values introduced in earlier patch.
Differential Revision: https://phabricator.services.mozilla.com/D84887
I believe this is correct for blending a non-premuliplied source into a premultiplied destination. Only the source color part should be different to normal blending, since it needs to be multiplied by the source alpha channel.
Differential Revision: https://phabricator.services.mozilla.com/D85716
This is not a feature-for-feature rewrite. The python version removes
unused things, and simplifies some others:
- Only two command line arguments are taken in, and all the others are
dropped and the corresponding values are gotten from the buildconfig
module instead. The command line arguments are also taken as
positional arguments rather than going with a full argument parser.
- Variable expansion in module.ver used to be limited to one specific
variable to expand for a given value, which is now replaced with the
possibility to expand any of the variables that are allowed in
module.ver.
- The perl version was adding a RT_MANIFEST entry on its own if a
manifest file existed in the objdir for the given binary, but if such
a file existed, the build would fail after linking from the changes in
bug 1613799.
- The perl version was defaulting the module name to the binary name in
a branch that was never taken because the module name was assigned to
an empty string before that.
The output from the new script has been validated to being identical to
the output from the perl script, except for one extra whitespace at the
end of a comment.
Differential Revision: https://phabricator.services.mozilla.com/D85817
The new pivot boundaries might consist of accessibles that don't exist
yet in the parent process proxy tree.
I guess we can tweak the timing of the pivot boundaries message to be
sent only after remote tree construction. But this seems like an edge
case that quickly gets corrected after the next cache refresh.
Differential Revision: https://phabricator.services.mozilla.com/D85912
Change the GamepadEventChannel so it is fully-initialized by the IPC
constuctor and needs no separate "init" message, and so its completely
destroyed by the ActorDestroy() message so it needs no "cleanup" message.
This simplifies the object lifetime, as well as unifies the IPC error vs
clean shutdown paths.
Differential Revision: https://phabricator.services.mozilla.com/D85481
