There are scenarios where we have a TabParent in the UI process hooked up to
a PuppetWidget with a BasicLayerManager. Webextensions fall into this category.
In this scenario, the parent-side layer manager is not hooked up to
the compositor (that is, there is no entry in the CompositorBridge layer tree
state map for the layers id). However, the content-side still ends up creating
a ClientLayerManager or a WebRenderLayerManager, which expects the layers id to
be registered in the compositor. This results in brokenness (in the case of the
ClientLayerManager/PLayerTransaction) or crashes (in the case of WebRenderLayerManager/
PWebRenderBridge). Instead, this patch changes this scenario to have the content
process use a BasicLayerManager which seems safer.
MozReview-Commit-ID: 3f80aZrRrmD
--HG--
extra : rebase_source : 10ec78dd7daf1c1c889929f0d79e0b75675b4b05
Instead we can use the otherwise-unused function to check if initialization worked.
Technically, because of the way RenderFrame construction works, whether or not
initialization succeeds is exactly dependent on whether or not the frameloader is
non-null, so we could even just use that to check success. But this feels slightly
more readable/cleaner.
MozReview-Commit-ID: CGiIAA1h6V7
--HG--
extra : rebase_source : 2d4504f7d5fde3c394edca14fe01840c1738d197
There is already a GetLayersId function in RenderFrameParent.h that does the
exact same thing, and this private function is only used in one spot. Seems
unnecessary.
MozReview-Commit-ID: 6i7lwKQsSFM
--HG--
extra : rebase_source : 6cf688f6f4300bedffebfbb94d431deec0bff209
The FFI type conversion in AnimationValue::as_arc will check if the
parameter is nullptr or not. If it is, we will get a debug assertion, so
we shouldn't pass a nullptr into it.
MozReview-Commit-ID: KWko2ipJwbo
--HG--
extra : rebase_source : f3e284da008b6c3bb3c56eb26c485f825b1188a7
We will obsolete StyleAnimationValue in the future, and can treat
AnimationValue as a wrapper of RawServoAnimationValue to hide the FFIs
at that moment. For now, we still need both types, so it's better to make sure
they are mutually exclusive in AnimationValue. Therefore, let's add some
assertions.
Besides, I think those FFIs might do many things and it seems those methods
are not critical, so let's move them into the cpp file, so we can remove
some dependencies to avoid re-compiling so many files if someone needs
revise ServoBindings.h.
MozReview-Commit-ID: FJ1uTvEQ7NT
--HG--
extra : rebase_source : 8ef99c659f2721c8425364051db19b66536bccc6
This patch also changes the 'headerURL' and 'theme_frame' properties to be of type
ExtensionURL, instead of strings. This improves validation robustness.
Alignment and tiling properties for the additional background images can be
specified in the newly introduced 'properties' section of the manifest.
MozReview-Commit-ID: BzvS3eHmDCY
--HG--
extra : rebase_source : 03560c0441bd2a6643c20a3f1fff8b905eca59ad
It deserves more investigation, we should probably clear NAC data on
ServoRestyleManager::ClearServoDataFromSubtree, but not worth to keep the tree
orange meanwhile.
Source-Repo: https://github.com/servo/servo
Source-Revision: e69bc2e0d32ebfc88863380c4dd3418cc21dd1c3
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 10bc6b7f9316e67f0cf92b9887f061cc67d3417d
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#16213
Source-Repo: https://github.com/servo/servo
Source-Revision: e2671459cbf548eed4399a959c3a870880482778
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 519eff56b93db10257e710eda875a579b3beeea6
This fixes the failure of
layout/reftests/css-grid/grid-min-max-content-sizing-002.html with the
primary patch in bug 1308876 (which causes a child whose parent is dirty
to pick up the dirty bit from the parent only the first reflow of the
child if the parent reflows the child multiple times). A simplified
testcase for that failure is
https://bugzilla.mozilla.org/attachment.cgi?id=8849771 .
The failure was caused by an error in height calculation of the first
<x> in the test. The div that is the parent of that x has a definite
height (presumably due to rules in grid), and the x has a specified
height. The div gets three reflows: two measuring reflows (from
MinContentContribution and then from MaxContentContribution) and then a
final reflow from nsGridContainerFrame::ReflowInFlowChild. Prior to the
primary patch in this bug, the div was marked dirty on all three
reflows, but with it it is marked dirty only on the first. This means
that, without the block-resize flag, the div optimizes away the reflow
of its children, since ShouldReflowAllKids returns false because
IsBResize() is false, even though NS_FRAME_CONTAINS_RELATIVE_BSIZE is
correctly set.
In order to fix this, we need to make sure the BResize flag on the
reflow state in at least some cases (see the comments in the patch for
when, and for how the cases could be optimized in the future).
Note that:
* when the dirty bit is set on the grid container, the new behavior
(with the combination of the patches) is strictly more efficient than
the old, since we will sometimes do non-dirty reflows on the grid
items (with the b-resize flag)
* when the dirty bit is *not* set on the grid container, the new
behavior is less efficient than the old, since we will set the
b-resize flag when we did not do so before. However, this slowdown
fixes existing bugs such as the one in the reftest.
Given that I was able to construct a reftest that triggers the failure
without the changes from bug 1308876, I've moved this to a separate bug.
Without the patch, grid-measuring-reflow-resize-dynamic-001.html fails,
but grid-measuring-reflow-resize-static-001.html passes. With the patch
both tests pass. (And without the patch, doing a text zoom on the
dynamic test fixes the layout error.)
MozReview-Commit-ID: JQOdVTQIkU0
--HG--
extra : transplant_source : %8B%2ARO%3B%D0%7B%EC%C9_%B3%60Sp%F9T%14X%85%DC
These files were being excluding because we thought they used plarena.h, but it
turns out they did not. A few tweaks needed to be made to clarify whether we
wanted to use mozilla::UniquePtr or js::UniquePtr.
MozReview-Commit-ID: 1su5dO3rR0T
This updates the unifed sources for a few netwerk build files. In some cases
files were excluded because we thought they used plarena.h, but that turned
to be false.
A few files needed to be updated to add missing imports/exports due to shifting
of compilation units.
MozReview-Commit-ID: 4mh8VApFoe1
Wes Kocher
ffxbld
Kartikaya Gupta
Carsten "Tomcat" Book
Jon Coppeard
Cameron McCormack
Benjamin Bouvier
Jan de Mooij
Boris Chiou
Mike de Boer
Emilio Cobos Álvarez
philipp
Edouard Oger
Jared Wein
Sebastian Hengst
Josh Matthews
Dão Gottwald
Iris Hsiao
Franziskus Kiefer
Felipe Gomes
Geoff Brown
L. David Baron
Scott Wu
Edgar Chen
Phil Ringnalda
Eric Rahm
Nicholas Nethercote
Sean Stangl