This is done with the following script:
```python
#!/usr/bin/env python3
import re
import subprocess
LIST_FILE = "layout/style/nsCSSKeywordList.h"
RE_KEYWORD = re.compile(r"\beCSSKeyword_(\w+)")
rg_result = subprocess.check_output(["rg", r"eCSSKeyword_\w+"], encoding="UTF-8")
to_keep = set()
for item in rg_result.splitlines():
file, line = item.split(':', 1)
for m in RE_KEYWORD.finditer(line):
to_keep.add(m.group(1))
remaining_lines = []
RE_ITEM = re.compile(r"CSS_KEY\(.+, (\w+)\)")
with open(LIST_FILE, "r") as f:
for line in f:
m = RE_ITEM.search(line)
if m is not None and m.group(1) not in to_keep:
print("Removing " + m.group(1))
continue
remaining_lines.append(line)
with open(LIST_FILE, "w", newline="") as f:
f.writelines(remaining_lines)
```
MozReview-Commit-ID: upyTPc8984
--HG--
extra : source : 65a744682fe99d8f0de4fa4b7a478e10aba0349e
This is done with the following script:
```python
#!/usr/bin/env python3
import re
import subprocess
from pathlib import Path
HEADER = Path("layout/style/nsCSSProps.h")
SOURCE = Path("layout/style/nsCSSProps.cpp")
RE_TABLE = re.compile(r"\b(k\w+KTable)")
rg_result = subprocess.check_output(["rg", r"\bk\w+KTable"], encoding="UTF-8")
to_keep = set()
all = set()
for item in rg_result.splitlines():
file, line = item.split(':', 1)
name = RE_TABLE.search(line).group(1)
path = Path(file)
if path != HEADER and path != SOURCE:
to_keep.add(name)
else:
all.add(name)
to_remove = all - to_keep
remaining_lines = []
with HEADER.open() as f:
for line in f:
m = RE_TABLE.search(line)
if m is not None and m.group(1) in to_remove:
print("Removing " + m.group(1))
continue
remaining_lines.append(line)
with HEADER.open("w", newline="") as f:
f.writelines(remaining_lines)
remaining_lines = []
removing = False
RE_DEF = re.compile(r"KTableEntry nsCSSProps::(k\w+KTable)\[\]")
with SOURCE.open() as f:
for line in f:
if removing:
if line == "};\n":
removing = False
continue
m = RE_DEF.search(line)
if m is not None and m.group(1) in to_remove:
if remaining_lines[-1] == "\n":
remaining_lines.pop()
removing = True
continue
remaining_lines.append(line)
with SOURCE.open("w", newline="") as f:
f.writelines(remaining_lines)
```
MozReview-Commit-ID: FeDZRcBceqV
--HG--
extra : source : fe9369e5cef11a6c6eaac641c185844eb45554b1
This is done with the following script:
```python
#!/usr/bin/env python3
import re
import sys
from pathlib import Path
if len(sys.argv) != 2:
print("Usage: {} objdir".format(sys.argv[0]))
exit(1)
generated = Path(sys.argv[1]) / "layout" / "style"
generated = generated / "nsComputedDOMStyleGenerated.cpp"
RE_GENERATED = re.compile(r"DoGet\w+")
keeping = set()
with generated.open() as f:
for line in f:
m = RE_GENERATED.search(line)
if m is not None:
keeping.add(m.group(0))
HEADER = "layout/style/nsComputedDOMStyle.h"
SOURCE = "layout/style/nsComputedDOMStyle.cpp"
# We need to keep functions invoked by others
RE_DEF = re.compile(r"nsComputedDOMStyle::(DoGet\w+)\(\)")
RE_SRC = re.compile(r"\b(DoGet\w+)\(\)")
with open(SOURCE, "r") as f:
for line in f:
m = RE_DEF.search(line)
if m is not None:
continue
m = RE_SRC.search(line)
if m is not None:
keeping.add(m.group(1))
removing = set()
remaining_lines = []
with open(HEADER, "r") as f:
for line in f:
m = RE_SRC.search(line)
if m is not None:
name = m.group(1)
if name not in keeping:
print("Removing " + name)
removing.add(name)
continue
remaining_lines.append(line)
with open(HEADER, "w", newline="") as f:
f.writelines(remaining_lines)
remaining_lines = []
is_removing = False
with open(SOURCE, "r") as f:
for line in f:
if is_removing:
if line == "}\n":
is_removing = False
continue
m = RE_DEF.search(line)
if m is not None:
name = m.group(1)
if name in removing:
remaining_lines.pop()
if remaining_lines[-1] == "\n":
remaining_lines.pop()
is_removing = True
continue
remaining_lines.append(line)
with open(SOURCE, "w", newline="") as f:
f.writelines(remaining_lines)
```
MozReview-Commit-ID: ACewvZ9ztWp
--HG--
extra : source : 7f167f9affd954da907d1da307ebc82be4b85911
This changes the order of properties returned from gCS. The old order
doesn't make much sense, and other browsers don't agree on an identical
order either, so it should be trivial to change it. Also the spec isn't
super clear / useful in this case.
Several -moz-prefixed properties are excluded from the list due to their
being internal. I suspect they are never accessible anyway, so probably
nothing gets changed by this.
MozReview-Commit-ID: 9LfangjpJ3P
--HG--
extra : source : 879a7265c35f51c5954d8a44ccd374a606ecba0e
The idea with this patch is that style code will first call
InlineStyleDeclarationWillChange before style declaration has changed, and SetInlineStyleDeclaration once it has changed.
In order to be able to report old attribute value, InlineStyleDeclarationWillChange reads the value and also calls AttributeWillChange (so that DOMMutationObserser can grab the old value). Later SetInlineStyleDeclaration passes the old value to
SetAttrAndNotify so that mutation events and attributeChanged callbacks are handled correctly.
Because of performance, declaration can't be cloned for reading the old value. And that is why the recently-added callback is used to detect when declaration is about to change (bug 1466963 and followup bug 1468665).
To keep the expected existing behavior, even if declaration isn't changed, but just a new declaration was created (since there wasn't any), we need to still run all these
willchange/set calls. That is when the code has 'if (created)' checks.
Since there are several declaration implementation and only nsDOMCSSAttributeDeclaration needs the about-to-change callback, GetPropertyChangeClosure is the one to initialize the callback closure, and the struct which is then passes as data to the closure.
Apparently we lost mutation event testing on style attribute when the pref was added, so test_style_attr_listener.html is modified to test both pref values.
--HG--
extra : rebase_source : 9e605d43f22e650ac3912fbfb41abb8d5a2a0c8f
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
The EffectSet count does not exactly represent the count what we really need
for AnimationValueMap, but in most cases it matches. For example;
1) The element has two different keyframes animations
@keyframes anim1 {
to { opacity: 0; }
}
@keyframes anim2 {
to { transform: rotate(360deg); }
}
In this case the number matches.
2) The element has two animations but both keyframes have the same CSS property
@keyframes anim1 {
to { opacity: 0; }
}
@keyframes anim2 {
to { opacity: 0.1; }
}
In this case the number doesn't match, moreover it results more memory than we
ever needed, but this case is presumably less common.
3) The element has an animation having keyframes for two different CSS
properties.
@keyframes anim {
from { opacity: 0; transform: rotate(360deg); }
}
In this kind of cases, the number doesn't match. But even so, this patch
reduces the opportunities that the AnimationValueMap tries to allocate a new
memory (i.e. less opportunities on expanding the map).
Note that when the hash map is expanded, we do allocate a new RawTable with the
new size then replace the old one with the new one [1], so I believe this
change will reduce the crash rate to some extent.
[1] https://hg.mozilla.org/mozilla-central/file/15c95df467be/servo/components/hashglobe/src/hash_map.rs#l734
MozReview-Commit-ID: 6tcF9aqXh7a
--HG--
extra : rebase_source : 366989d3a2756f5a5711503a57f42f3b746d93a5
We were spuriously reframing the <shadow> because it initially shared style with
the <br>, which ended up being display: none, while the <shadow> should've been
display: contents from the beginning.
lookup_by_rules seems pretty prone to obscure bugs, and also it's pretty
complex... Probably we should try to get rid of it, I'm unconvinced that it's
worth it.
Even with that, in a normal restyle the <details> wouldn't have ended up with a
style. It of course never had it before the reframe because the <shadow> was
display: none, but that doesn't mean it shouldn't have gotten one, since we
detected we needed to go through kids in:
https://searchfox.org/mozilla-central/rev/6eea08365e7386a2b81c044e7cc8a3daa51d8754/servo/components/style/matching.rs#500
That code did happen, but since it's an animation-only restyle, we don't look at
unstyled stuff.
That looks somewhat fishy, but I guess for now it's fine as long as display
isn't animatable.
MozReview-Commit-ID: B6NMSTNOKgK
Do it so that we always try to evaluate the media expression and the modern
syntax last, so that the most specific error message comes up.
MozReview-Commit-ID: 2tqdAsWh6Kh
There's a bunch of others in WPT already, so I don't think it's worth going
through absolutely all of them...
MozReview-Commit-ID: LmGXyVkcOGm
--HG--
extra : rebase_source : 3af5786a0c6d16c95ddb9c639fc61442c4116caf
