This reverts commit 1970e82b0d310128eabe8466d39d42cc20e7ae4b, reversing
changes made to e882660ea694f9f12d9d2936012dbdf192f8aec8.
The reparenting logic is still bogus, but I'll figure out how to deal with that
in a bit.
Source-Repo: https://github.com/servo/servo
Source-Revision: be7d13e37fad6eb594a7b8c8ec9b07fa0df11116
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6466a27a0b5271a78c3d00357de1db4e14495b17
In practice the only NAC that possibly inherits from a grid or flex container
are pseudos.
In Gecko, if the root element is an item container, custom anon content would
also sometimes incorrectly inherit from that (see bug 1405635), but that's fixed
in Stylo.
We remove the IS_ROOT_ELEMENT blockification from the "skip display fixup"
check, since the root element is never NAC or anything like that, so there's no
need for the check.
This also fixes some reparenting fishiness related to pseudo-elements. We were
only skipping the fixup when reparenting anon boxes, not when reparenting normal
element styles, nor when reparenting other pseudo styles which are not anon
boxes.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1970e82b0d310128eabe8466d39d42cc20e7ae4b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6633420bdbfffc8a284fa7d804cb48ed0ab20cae
Reland of #19660 since it was backed out for not landing its Gecko changes on time.
Bug: 1427001
Reviewed-by: smaug
MozReview-Commit-ID: Cq647BcOzbe
Source-Repo: https://github.com/servo/servo
Source-Revision: e882660ea694f9f12d9d2936012dbdf192f8aec8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6c1039bb1853cd340a0170a73d43f8d4331e7bcc
This will allow #19659 to use derive on display using:
#[parse(aliases = "-webkit-flex")]
Flex,
#[parse(aliases = "-webkit-inline-flex")]
InlineFlex,
And such.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4ba795081cd1efa42ce03c996d574cfe96f68ece
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 7157dd2b10e6e39595ae090ad40219fd012b7baf
On top of #19661.
The NAC condition is pointless because NAC don't match author rules unless they
are a pseudo-element too.
Source-Repo: https://github.com/servo/servo
Source-Revision: ebff37b80720447044cc38553558e8339512144f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 12bd00a0a939f3b61b22f1db2073dc49e4c58f9b
The style adjuster knows about the pseudo, so there's no reason to thread that
info down.
There are more simplifications that can be done in followups, cleaning a bit the
cascade flags too, those will come later.
Source-Repo: https://github.com/servo/servo
Source-Revision: fb569f9c159627a058b902bfe820f55c2657e590
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9edac6e97fe86837e59d333cb2ce084cda2ab083
The nsGIOService now provides GetAppsForURIScheme which is used to append handlers
for specific scheme in handler list dialog (toolkit/mozapps/handling/content/dialog.js)
and also in Applications section in preferences. In case the default system handler
or user added handler has same name as one of the GIO handlers, the GIO handler
is not appended. The check for not adding handler is by using handler name.
The nsGIOMimeApp class now implements nsIHandlerApp interface. Instead overloaded
GetName methods (nsCString and nsString) we now use nsString variant everywhere.
This require change of nsGNOMERegistry::GetFromType which if fact leads to code
simplification.
The implementation of nsGNOMEShellService::SetDefaultBrowser has been changed
because implementation of CreateAppFromCommand has changed.
The CreateAppFromCommand no longer tries to find the application,
for that FindAppFromCommand has been introduced.
MozReview-Commit-ID: KmfFWRPqV3
--HG--
extra : source : 9660ff09c2212cb7456e50cb166752f42e0a0669
extra : amend_source : 3c5fc61fe09b9b68bdfbb9683335cedd4d706744
The nsGIOService now provides GetAppsForURIScheme which is used to append handlers
for specific scheme in handler list dialog (toolkit/mozapps/handling/content/dialog.js)
and also in Applications section in preferences. In case the default system handler
or user added handler has same name as one of the GIO handlers, the GIO handler
is not appended. The check for not adding handler is by using handler name.
The nsGIOMimeApp class now implements nsIHandlerApp interface. Instead overloaded
GetName methods (nsCString and nsString) we now use nsString variant everywhere.
This require change of nsGNOMERegistry::GetFromType which if fact leads to code
simplification.
The implementation of nsGNOMEShellService::SetDefaultBrowser has been changed
because implementation of CreateAppFromCommand has changed.
The CreateAppFromCommand no longer tries to find the application,
for that FindAppFromCommand has been introduced.
MozReview-Commit-ID: KmfFWRPqV3
--HG--
extra : rebase_source : 36d254cbc45cbe6929cc469cd531211f7ddd6a64
libcrypto, part of OpenSSL, and that dmg links against, has a varying
ABI, and something built against libcrypto on Centos won't run on Debian
and vice versa. It might not even work between versions of the same OS
(e.g. Debian 7 vs. Debian 9).
Because of that, it is desirable to statically link it.
This incorporates https://github.com/mozilla/libdmg-hfsplus/pull/1
and sets OPENSSL_USE_STATIC_LIBS when building libdmg-hfsplus.
--HG--
extra : rebase_source : 21a46f707494f388a899c08d0923f8b393d12cd1
I was able to reproduce the failure to apply llvm-dsymutil on the last
mozilla-central revision before debug info was temporarily disabled for
rust, and validated that the problem was gone in clang 4.
After some bisection, r289565 was identified as having fixed the
problem, which, reading the commit message, makes sense.
It was however not possible to simply cherry-pick, because of multiple
code changes between 3.9 and 4. However, apart from the volume of
conflicting changes, it was more or less straightforward to backport.
Interestingly, the patch for r313872 was relying on changes from
r289565, which is why it required a variant specifically for 3.9, but
now we can use the same patch as for other versions. Well, except
there's a small difference in the context, and build-clang.py doesn't
allow fuzz, so we manually edit the patch to remove that line from the
context.
--HG--
extra : rebase_source : de0ab262d401c37c0e9300b0ef7923a07c009d87
fontconfig uses expat by default to read its xml configuration, but when
expat is not there at build time, it falls back to libxml2. We ended up
in this situation, while on Debian, fontconfig is built against expat.
This makes no practical difference, since we're not actually using
fontconfig, but for some reason, the difference in dependencies has an
impact on how ld chooses to arrange the .plt and .got.plt sections,
meaning that even though the code and data is originally identical, in
the .o files, the resulting linked machine code is largely different
because of all the applied relocations changing the offsets of e.g. call
instructions for function calls through the .plt. This results in large
differences in .plt, .init, .text, .data.rel.ro, as well as symbols list
when building on Debian.
This thus is meant to help make the differences more tractable.
--HG--
extra : rebase_source : 7a731c34074a50e84412f73ab9499248345fb14a
In bug 1426785, Gtk+3 build was moved to docker image creation time, and
at the same time, the removal of .la files was stripped, because it
seemed too broad to do that in /usr/local/lib*, and because I didn't
really remember why it was there in the first place.
I now do remember, and that's because libtool likes to add useless
dependencies on libraries just because direct dependencies transitively
depend on them. For example, this adds a dependency on libffi to
libpangocairo, which doesn't use it directly.
I also happens that /usr/local/lib* is empty at the moment we build
gtk3, so we can just do the cleanup there.
On its own, this change is useless, but:
- it restores the libraries in their state pre-bug 1426785,
- it helps reduce some differences when building on Debian (for bug
1399679), easing the comparison of those builds.
--HG--
extra : rebase_source : 3fa644d8ae5eb4ccac5940c7d3605201f589936d
This is a sub-PR of #19015
r? emilio
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19645
- [x] These changes do not require tests
Source-Repo: https://github.com/servo/servo
Source-Revision: 446536b9c34b331f5466bfb212be8cb1faa2dee8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 95d2c35265415ad7c93319d1364efa59f49cdaad
