Bug 1365460 introduced code paths behind MOZ_DEBUG #ifdefs, but
MOZ_DEBUG is never defined, while it is available in CONFIG in
moz.builds. This is kind of a confusing situation, but the fact that
we've been able to avoid those problems for so long would tend to
put the blame on mozjemalloc, and fixes should go there.
Except that bug 1261161 explains that the only existing alternative
(the DEBUG #define), as used in MFBT, is not working for spidermonkey,
so it actually makes sense to converge to MOZ_DEBUG rather than DEBUG.
So start defining MOZ_DEBUG globally, fixing the mozjemalloc issues of
not having the debug code enabled. Bug 1261161 can then take care of
changing the DEBUG #ifdefs.
--HG--
extra : rebase_source : 37e3d03ac8350c62c8059d4ca01d1ecfdf5f421a
The way inlining is disabled in mozjemalloc is via a #define of "inline"
to nothing, which is a dubious way to do that. This makes the compiler
trigger warnings we -Werror on for some static functions. While there
are such functions in mozjemalloc.cpp that could be fixed by wrapping
them in the right #ifdefs, there are also others coming from headers,
and it's not something that can be fixed in a satisfactory way.
The right way to disable inlining is to pass the right compiler flags
for that. But inlining is the least of the problems to debug optimized
C++ code, so it feels like if debugging requires some optimization
tweaking, it should be done manually with compile flags when needed,
instead of fiddling with #defines to remove keywords.
--HG--
extra : rebase_source : 962c3409f86060c4d5ddf966778b58b64f89c31d
Instead of unconditionally pushing and popping clips per display item,
this patch changes things so that for each recursive display list, we
create an ItemClips struct. We push this onto the stack when we enter
the display list, and pop it off at the end. For each display item, we
check to see if the clips would actually change compared to the previous
display item, and only do the pop/repush in that case.
MozReview-Commit-ID: GadIp2J8TrA
--HG--
extra : rebase_source : ba64c6b4659b8e51cab19b807088b9a50d71b85a
This makes ScrollingLayersHelper a non-RAII type class, and instead adds
methods to notify it of when we start processing a new transaction or a
new display item within the transaction. This patch has no functional
changes, it's non-obvious refactoring.
MozReview-Commit-ID: 3yq9sPiHMge
--HG--
extra : rebase_source : 286423f56de59211e320f015cb1004a1e98332b8
Storing the per-item clip state in a struct like this will allow us to
easily compare the desired clip state across items, so we can avoid
doing unnecessary work when going from one item to the next. This patch
has no functional changes, it's just refactoring.
MozReview-Commit-ID: 49B6hmsWZ4V
--HG--
extra : rebase_source : 8ac4bbf039f81bc2d26e92924ed041fa3d18e5ba
Instead just keep a ref to it as a member variable. No functional
change.
MozReview-Commit-ID: 5fccUlSifsA
--HG--
extra : rebase_source : a14672f926c383354db76e553ae23613fe4a432a
Cargo 0.23.0-beta, included with Rust 1.22.0-beta.2, wants to
move the top-level package description out of the [root] section
of Cargo.lock and into a parallel [[package]] section.
Accept this update by temporarily running the build without
passing --frozen and committing the result.
This is accepted by the cargo versions included in the current
and previous stable rust releases, so it will work with all
supported toolchains.
MozReview-Commit-ID: 1hMykhTknHi
--HG--
extra : rebase_source : 153d2016cd5e637584ea1d755198fbd1a5e7067e
One of the sticky-pos tests was only passing because of two wrongs that
cancelled each other out in the old code. Specifically, instead of
defining a nested clip with the sticky clip as an ancestor, the clip was being
defined with the root ASR as an ancestor. Both resulted in the nested
clip not scrolling with the actual scrolling scrollframe and so the test
was passing.
The new code changes things so that the nested clip is defined with the
actual scrolling scrollframe as the ancestor, causing the reftest to fail.
Fixing the clip ancestry is not hard but it reveals other problems so
so I'm deferring that to a follow-up bug.
MozReview-Commit-ID: DldAKi1AP4l
--HG--
extra : rebase_source : a448e06fd26fff21bbc4a6f50e04dbbdb427298c
This handles some cases where a nested display item's clip chain
implicitly extends from the wrapper item's clip chain.
MozReview-Commit-ID: DmghxOWi81K
--HG--
extra : rebase_source : 8ec95df64fed247650baf8f5e0c868d1934aa6bc
Bug 1409442 is tracking a change that will allow scroll layers to have
multiple ancestors. Without that, there are cases we cannot properly
handle, and so we need to ignore a clip in those scenarios. This patch
makes sure we do that instead of crashing.
MozReview-Commit-ID: 7AU4uyzT6if
--HG--
extra : rebase_source : d483c2a7ecff5cd488a53fa5e6b6da55cc3a1e29
When display items (such as mask items) push an out-of-band clip, we
can't use clip ids from, or update clip ids into, the cache. We also
need to ensure we take these out-of-band clips into account when
determining the parent for a new clip we are going to define.
MozReview-Commit-ID: GcUI2Hf6SLB
--HG--
extra : rebase_source : 512be5a6998b9c1d6db9d8c550231f0883d721c9
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
This code is more straightforward in its recursion than the old code,
and provides a relatively clean way to explicitly pass the desired
parent when defining a new clip or scroll layer.
Refer to the documentation in the patch for more details.
Note that this patch provides the basic recursive algorithm to define
the clips and scroll layers, although it omits some of the complicating
edge cases which will be added in later patches. The new code is not
invoked from anywhere until all the edge case handling has been done.
MozReview-Commit-ID: 7z51Kd7LlPU
--HG--
extra : rebase_source : 491efac9282a7379f7977a1bc0205ac70e356c3c
By using a variant we can keep a single stack of both clips and
scrollframes, rather than two separate stacks. This is important because
we will want to know how the things are interleaved (e.g. if the last
thing that was pushed was a clip or a scrollframe).
MozReview-Commit-ID: DbhDj2tTq64
--HG--
extra : rebase_source : c591787f31e6ba864178e27197cf6dff42e39a8d
We don't use the code to track the parents of each scroll id, so we can
dump it and just keep a set of scroll ids that we've defined to avoid
redefining them.
MozReview-Commit-ID: HY8y7xt9AJ6
--HG--
extra : rebase_source : 681154ae6494330f74c022243237b50d4921813b
The APIs now allow providing the parent clip or scroll info explicitly
instead of having to push it on the stack. For now we just pass
Nothing() to preserve the existing behaviour, so this change is a
functinoal no-op.
MozReview-Commit-ID: dtNamN595
--HG--
extra : rebase_source : 3b6bd03b919bd31cd89e3f82283cb962f8f6abc5
That is, in cases where it would fail to link.
This will help make Rust CI be gated on compiling Stylo: https://github.com/rust-lang/rust/pull/44603
Source-Repo: https://github.com/servo/servo
Source-Revision: 38fe9533b93e985657f99a29772bf3d3c8694822
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 3a2413e03efb4754cf657f4637a3543fbc13074a
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they should not change behavior.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: f26aa3b016beb5717d8a53477c162dd832b24d7e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : afcd2a0b7b9b5d21776cb7fcc775f9046f8b94e9
We don't need them anymore
Source-Repo: https://github.com/servo/servo
Source-Revision: 69b9c221f65243562a5dc54cba45a083d1d046cc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : fa9cedf5cb5224af165963f07b16a1ab5ac24469
This is the servo side of bug 1403213.
Take 2 of #18941 which got backed out because we botched the landing of the gecko side and I wasn't able to fix it in time.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0e6946fd9c279425e66721e6eb2b1e323e4c640f
--HG--
rename : servo/components/style/gecko_bindings/nsstring_vendor/src/lib.rs => servo/support/gecko/nsstring/src/lib.rs
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6d2fb196b2ed25c0201097d20e07b2e757096d00
We're a couple years behind master at this point.
Source-Repo: https://github.com/servo/servo
Source-Revision: 00784fe5e1f6410a928655d606ccaf73f37984b7
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : cc48b9092add00152ea4d43a5015ee910bafa7c5
Fix for a bug I didn't catch in #18957. Thanks to @rharel for pointing it out.
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix issue #18943 and bug in PR #18957
- [X] These changes do not require tests as specified in #18943
r?@jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: d9ede4dc054ba2da322bd21af1cfa75b85e1dc65
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 1c9a0a4e837e82aea6541509c2b01a12764b1b0e
In Gecko, we handle XBL rules like author rules everywhere, except that XBL rules are added and sorted in an independent step, behave as if it has a separate level.
It is not clear to me why Stylo chose to add a separate level for XBL rules, but it doesn't seem that there is anything special to do with XBL rules.
This bug happens because we don't handle XBL important rules which are handled as part of author rules in Gecko due to lack of the additional level there. We should just follow what Gecko does here and handle them all the same.
(This is the Servo part of [bug 1408811](https://bugzilla.mozilla.org/show_bug.cgi?id=1408811))
Source-Repo: https://github.com/servo/servo
Source-Revision: 819dff79087d2c45203d97f9837dd0e07513304e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e51cdc33ed34941e4b8617e2dd89dea4b92d8f9e
