Note that we also drop the dead optional aReusableSheets argument from
the async parsing path, since it was always null.
MozReview-Commit-ID: KddpGFdaqEe
Assuming we call MarkIntrinsicISizesDirty in the appropriate scenarios, this
patch shouldn't change behavior - it just caches these values so we don't
needlessly recalculate them.
MozReview-Commit-ID: 8QY4AZJXshy
--HG--
extra : rebase_source : a7c87b03ac8240ba71efd2198ce1976d96c91f64
This patch does not change behavior; it just merges the implementations of
these two functions into a single common function.
MozReview-Commit-ID: BqsRt3p2NQT
--HG--
extra : rebase_source : e8792f2bed3fd0708ffb38b91cf15a78cb6fbd59
Some content in Makefile.in is removed because after this change, the
scripts no longer invoke the preprocessor and thus don't have unknown
dependencies anymore outside what is provided in their inputs array.
The order of exports.PREFERENCES in properties-db changes because the
data file has shorthands placed after longhands. The only usage of it
is in test_css-properties-db.js which doesn't care about the order.
MozReview-Commit-ID: AMjzTRf2HYN
--HG--
extra : rebase_source : f9db0659a81bea28b335806ac70e23dc0d36e493
With this change, we first generate a data file ServoCSSPropList.py from
Servo data, and then use this data to generate ServoCSSPropList.h.
This change itself serves as a checkpoint with a runtime check that all
information generated from Servo side matches what we have in the Gecko
side. Following patches will start replacing uses of nsCSSPropList.h
with either the data file or the header file.
The reason that it generates data file rather than header directly is
that, many users of PythonCSSProps.h invokes C++ preprocessor manually
to extract data from nsCSSPropList.h without passing in search paths,
so it is non-trivial to replace the use of nsCSSPropList.h there with
a generated header. Generating a Python data file would hopefully
simplify those users rather than adding more complexity to them.
I also thought about generating JSON rather than plain Python file, but
JSON doesn't allow trailing comma in array, which makes it less pretty
to generate via mako template.
MozReview-Commit-ID: CwK2oL88r6F
--HG--
extra : rebase_source : 926cca8548d42ecb0dd364ea5c52a46a4973e819
This patch goes through and changes a bunch of places in our tree which mention
this bug to use the new feature, making the methods more strongly typed.
There are probably more places in tree which could be changed, but I didn't try
to find them.
In the previous patch, one of the files which was deleted is ShimInterfaceInfo.
This is an implementor of nsIInterfaceInfo which exists for legacy reasons, in
order to allow Components.interfaces.nsIDOM* to have the correct constants and
IIDs associated with them.
As that file was deleted, this information now has to be stored in the typelib.
To do this, the information is moved to the xptshim and xptshimfile attributes
on the relevant xpcom interfaces.
xptshim(...) means that this xpcom interface is a shim for the WebIDL interface
with the specified name.
xptshimfile(...) is for use when the webidl interface is declared in another
interface's .webidl file, (in our case, MessageManager.webidl). It contains the
name of the parent binding, such that we can #include the correct file in our
generated code.
This patch does not add the code which uses these changes, only the parsing
logic.
Move the assertion to the earliest point where it can happen instead, and do it
automatically on exit if it's generated content instead of relying on manual
calls.
MozReview-Commit-ID: 5oPwXg2o22V
This also adopts the resolution of [1] while at it, and switches XUL to not
support display: contents until a use case appears.
This makes our behavior consistent both with the spec and also in terms of
handling dynamic changes to stuff that would otherwise get suppressed.
Also makes us consistent with both Blink and WebKit in terms of computed style.
We were the only ones respecting "behaves as display: none" without actually
computing to display: none. Will file a spec issue to get that changed.
It also makes us match Blink and WebKit in terms of respecting display: contents
before other suppressions, see the reftest which I didn't write as a WPT
(because there's no spec supporting neither that or the opposite of what we do),
where a <g> element respects display: contents even though if it had any other
kind of display value we'd suppress the frame for it and all the descendants
since it's an SVG element in a non-SVG subtree.
Also, this removes the page-break bit from the display: contents loop, which I
think is harmless.
As long as the tests under style are based in namespace id / node name /
traversal parent, this should not make style sharing go wrong in any way, since
that's the first style sharing check we do at [2].
The general idea under this change is making all nodes with computed style of
display: contents actually honor it. Otherwise there's no way of making the
setup sound except re-introducing something similar to all the state tracking
removed in bug 1303605.
[1]: https://github.com/w3c/csswg-drafts/issues/2167
[2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700
MozReview-Commit-ID: JoCKnGYEleD
And fix a comment mentioning nsCSSSelectorList that I came across.
MozReview-Commit-ID: 1BOcDqV5dUr
--HG--
extra : rebase_source : 5fbdae6da74cf4fac145fbdd721723e81839e4b3
