This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
We have a fair number of files that have a particular stale version of the MPL
boilerplate. (It was probably originally correct, and then the official
boilerplate changed, and the stale MPL boilerplate continued to propagate via
copypasting from neighboring files into newly-added files.)
This patch updates this stale MPL text (and *only* the MPL text) to the latest
version, which can be found at https://www.mozilla.org/en-US/MPL/headers/ and
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
MozReview-Commit-ID: 8WeBb8b0uRo
--HG--
extra : rebase_source : 2c3aa8d07ba23714501c9e26ad03625aeab36a7a
Before this patch, we had been checking each scrollable ancestor is scrolled
out of its scrollable ancestor. So if the target animating frame is at the
bottom of its scrollable parent and if half of the scrollable parent is
scrolled out of its ancestor, the animating frame was considered as 'in-view'.
MozReview-Commit-ID: BDueuF3cT4I
--HG--
extra : rebase_source : de1dead6e67a44691887c8364be23734c3b1adef
Most of this change is just fiddling with function signatures so that they take
a LayerManager* instead of a Layer* (or in some cases, both). This allows
the WebRender codepaths to pass a WebRenderLayerManager* instead of having to
produce a Layer* which it doesn't have.
MozReview-Commit-ID: Fb0C8OUVDin
--HG--
extra : rebase_source : e4c3324cfa20c295db85d5c09df8d8d77865bb6a
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 98da45bc7f2eaabd63ae226c505cb1580b5c8500
Instead of just keeping a count of how many "extra clips" (aka
out-of-band clips) we have pushed, track more complex information for
each clip. In particular, track the display item's normal clip chain, as
well as the clip id of the extra clip that was pushed. This will be
needed to override clip cache information in the next patch.
MozReview-Commit-ID: AWKDTkelhyL
--HG--
extra : rebase_source : 379e38550cf45d54862850f6c4aad0ac488f6ca9
If border & padding were ignored for sizing the containing block (which can
happen, if the containing block is a chlid of a XUL-collapsed frame), then we
don't need to subtract border & padding when computing the frame's content-box
size for its abspos descendants.
MozReview-Commit-ID: JGnzShl8m67
--HG--
extra : rebase_source : 1cead4ce6b403af634c8f9bde0852dce4ee7edc5
Before enable stylo, an image request is always been resolved before the
creation time of that request object[1].
As a result, in AddAndRemoveImageAssociations, we always associate the request
objects of style images with the given frame(since they are resolved).
After enable stylo, an image request is resolved after that object been created[2].
We may hit the assertion reported in this bug by the following senario:
1. AddAndRemoveImageAssociations is called. The image request is not resolved
yet, so we do not associate that frame with that image request.
2. That image request is been resolved via nsStyleXXXX::FinishStyle.
3. Style changed. AddAndRemoveImageAssociations is called again. We try to
dis-associate the frame with image request and hit this assertion since
this frame is not associate with any image request at step #1.
[1]
We use this constructor if the backend is gecko
https://hg.mozilla.org/mozilla-central/file/5ed2f3c94155/layout/style/nsStyleStruct.cpp#l2131
[2]
We use this constructor if the backend is stylo
https://hg.mozilla.org/mozilla-central/file/5ed2f3c94155/layout/style/nsStyleStruct.cpp#l2147
MozReview-Commit-ID: 22trSbdogUH
--HG--
extra : source : 835239788497126e3be33a0dbbb0543e94fc9f18
extra : amend_source : b3e94ac2c639d89bac4745350f88d3383e6faf76
