Bug 1449883 - Use `const nsStaticAtom* const` instead of `nsStaticAtom**` in some SVG .cpp files. r=jwatt The patch also removes some conditional tests involving unitMap[i] that are now redundant due to preceding null tests against unitAtom. MozReview-Commit-ID: CJpktlS4k15

Bug 1449883 - Use `nsStaticAtom* const` instead of `nsStaticAtom**` in SVGTests. r=jwatt MozReview-Commit-ID: JBqaxfrRNCn

Bug 1449883 - Use `nsStaticAtom* const` instead of `nsStaticAtom**` in nsSVGEnumMapping. r=jwatt MozReview-Commit-ID: DRCUIaHY5SX

Bug 1449883 - Use `nsStaticAtom* const` instead of `nsStaticAtom**` in nsSVGElement.h. r=jwatt The patch also const-ifies a bunch of nearby fields. MozReview-Commit-ID: IId52fm3Y7j

Bug 1449827 - Optimize static atom use in nsTreeSanitizer. r=hsivonen The various AtomsTables in nsTreeSanitizer only contain static atoms. Knowing this, we can optimize things: - They can contain raw nsStaticAtom pointers instead of refcounted nsAtom pointers. - When looking up, we can/must first check if the atom we are looking for is static. If not, we know it can't be in the table. This is done by the new Contains() method. This change also lets us add more `const` to various places that interact with the tables. MozReview-Commit-ID: EFxWN2GU78L

Bug 1449827 - Introduce a typedef `AtomsTable` within nsTreeSanitizer. r=hsivonen This is much shorter than nsTHashtable<nsRefPtrHashKey<nsAtom>>, which is repeated often. MozReview-Commit-ID: 85MR0PQ6klI

Bug 1449827 - Use `nsStaticAtom* const` instead of `nsStaticAtom** const` in nsTreeSanitizer. r=hsivonen MozReview-Commit-ID: 4tk4BHbEpdt

Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer to the canonical pointer to that static atom. Which is pretty weird! The notable thing thing about it is that these structs are in an array, and that gives us the only way to iterate over all static atoms in a single class, for registration and lookups. But thanks to various other recent changes to the implementation of static atoms, we can now put the static atoms themselves into an array, which can be iterated over. So this patch does that. With that done, nsStaticAtomSetup is no longer necessary. According to the `size` utility, on Linux64 this reduces the size of libxul.so by the following amounts: > text: 62008 bytes > data: 20992 bytes > bss: 21040 bytes > total: 104040 bytes - The bss reduction is one word per atom, because the canonical static atom pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're now initialized at compile time instead of runtime. - The data reduction is one word per atom, because we remove two words per atom for the nsStaticAtomSetup removal, but gain one word per atom from the previous bullet point. - I'm not sure about the text reduction. It's three words per atom. Maybe because there is one less relocation per atom? Other notable things in the patch: - nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom, not nsAtom, because that's more precise. - Each static atoms array now has an enum associated with it, which is used in various ways. - In the big comment about the macros at the top of nsStaticAtom.h, the pre- and post-expansion forms are now shown interleaved. The interleaving reduces duplication and makes the comment much easier to read and maintain. The comment also has an introduction that explains the constraints and goals of the implementation. - The SUBCLASS macro variations are gone. There are few enough users of these macros now that always passing the atom type has become simpler. MozReview-Commit-ID: 1GmfKidLjaU

Bug 1449395 - Remove unnecessary nsStaticAtom.h includes. r=froydnj For nsCSSAnonBoxes.cpp, nsCSSPseudoElements.cpp, nsDirectoryService.cpp, the corresponding .h file includes nsStaticAtom.h. For the other files in this patch, nsStaticAtom.h is not needed at all. MozReview-Commit-ID: IpMmbXwZHhu

Bug 1449087 - Use Servo data to back @font-face rule. r?emilio This patch does the following things: * Create a new class ServoFontFaceRule for CSSOM of @font-face rule which mostly follows how nsCSSFontFaceRule was implemented. * Remove the old nsCSSFontFaceRule and binding code to create it. * Have FontFace backed by Servo data via making mRule and mDescriptors of the class hold RawServoFontFaceRule like ServoFontFaceRule. To keep this patch small, it effectively just delays the conversion from Servo data to nsCSSValue from parsing to using. This may cause worse performance if the font set is flushed repeatedly. Supposing we don't flush font set very frequently, it may not be a big deal. We may still want to remove the intermediate nsCSSValue conversion at some point, and have everything converted to their final form directly when used, but that can happen in followups. There are some unfortunate bits from this change: * We lose style sheet for logging in FontFaceSet. This is probably not all that worse, because we wouldn't have that before either if the page doesn't use CSSOM to visit it. But we should figure out some approach to fix it anyway. * InspectorFontFace no longer shares the same rule object as CSSOM. This isn't really a problem if the @font-face rule isn't very mutable. Unless we want to make the rule returned from InspectorFontFace to be mutable (i.e. via inspector), not using the same object probably isn't too bad. MozReview-Commit-ID: 32Fk3Fi9uTs

Bug 1450315 - Remove document.allowUnsafeHTML. r=bz This attribute was added in bug 1432966 when we started sanitizing chrome usage of innerHTML to allow devtools to use custom attributes in React via dangerouslySetInnerHTML. Devtools removed its usage of dangerouslySetInnerHTML in bug 1434155, so document.allowUnsafeHTML is no longer used and can be removed. MozReview-Commit-ID: 8xTVZDmPqRa

Bug 1450617: No need to ResolveTag to disable first-line on fieldsets. r?bz We don't extend HTML fieldsets with XBL, and I don't think we want to start doing that now. MozReview-Commit-ID: GiltTWXUBzZ

Bug 1450617: Remove resolved namespace id and tag from FCItems. r?bz Tag is unused, and now that the resolved XBL tag is only XUL the only checks the namespace id is used for don't need to account for it. MozReview-Commit-ID: 8IV3iF5xIs0

Bug 1450617: Only allow extending from / to XUL elements. r?bz MozReview-Commit-ID: JaFKQDkLGgw

Bug 509958: Unprefix :-moz-selection. r?dbaron,xidorn Our implementation is totally not what the spec says, but totally what other UAs do, see https://github.com/w3c/csswg-drafts/issues/2474. So given this is causing webcompat pain, I think we should be pragmatic and just unprefix this. We could keep serialization and getComputedStyle with ::selection working with a bit more effort, like we do for :-moz-placeholder, but I'd prefer not doing at least the serialization bit, and just alias in nsCSSPseudoElements :-moz-selection to selection too. MozReview-Commit-ID: 6lxctozRDqv

Bug 1339656: [css-align] Another pass of fixing align shorthand serialization. r?mats Hopefully the last one. This makes us serialize correctly when one of the longhands contains "unsafe", since we can indeed represent the value using the shorthand. It also fixes the test so that it tests something due to <overflow-position> was fixed to be first in bug 1430817. MozReview-Commit-ID: AnYBt6zwnPl

Bug 1303605: Make LazyFC assertions actually hold. r?bz So while removing that wallpaper I started hitting the !noPrimaryFrame assertions on XBL + HMTL stuff in display-contents-xbl-3.xbl. The code was trying to assert that we had frames constructed for all the nodes in the parent chain, but we don't bail out in the !GetContentInsertionFrameFor(aContainer) in the case that it's a children element, because they actually have no insertion frame, though their children do. Move the LazyFC check after the insertion point check. That makes the previous check work on the insertion point of the child, which makes it sound. This also fixes bug 1410020, and with it a Shadow DOM test-case that was failing because the content other slot wasn't getting properly flagged, and thus the slotted content never got a frame. The other two test failures in this test are an event dispatch failure, where the position of the target is not what the test expects (we don't account for margin and padding). Filed that as bug 1450027. Also, added a test for which we have wrong layout without these patches, and that crashes with "Called Servo_Element_IsDisplayNone" with the first applied but not this one, due to the bogus check mentioned above. MozReview-Commit-ID: 6OeaVrZhTDv

Bug 1303605: Remove the undisplayed maps. r?bz,mats This is mostly code removal, changing GetDisplayContentsStyle(..) checks by an FFI call to Servo. The tricky parts are: * MaybeCreateLazily, which I fixed to avoid setting bits under display: none stuff. This was a pre-existing problem, which was wallpapered by the sc->IsInDisplayNoneSubtree() check, which effectively made the whole assertion useless. * ContentRemoved, where we can no longer know for sure whether the element is actually display: contents if we're removing it as a response to a style change. See the comment there. That kinda sucks, but that case is relatively weird, and it's better than adding tons of complexity to handle that. * GetParentComputedStyle, which also has a comment there. Also, this function has only one caller now, so we should maybe try to remove it. The different assertions after DestroyFramesForAndRestyle are changed for a single assertion in the function itself, and the node bit used as an optimization to avoid hashtable lookups is taken back. MozReview-Commit-ID: AZm822QnhF9

Bug 1420680: Remove the user font cache generation, which is also unused now. r?jfkthame MozReview-Commit-ID: HuQg4RopOmX

Bug 1420680: Remove the mechanism to buffer CSP violations. r?bz With the previous patch it's unused. MozReview-Commit-ID: 4EKufeNu0Jz