abe717038847e73db56ab4db06ff7613a95f6959: Bug 1449883 - Use `const nsStaticAtom* const` instead of `nsStaticAtom**` in some SVG .cpp files. r=jwatt draft
Nicholas Nethercote <nnethercote@mozilla.com> - Tue, 03 Apr 2018 17:29:37 +1000 - rev 776498
Push 104891 by nnethercote@mozilla.com at Tue, 03 Apr 2018 07:30:23 +0000
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
72ba90cf84bba6f272324dc947693eef0ea6eeca: Bug 1449883 - Use `nsStaticAtom* const` instead of `nsStaticAtom**` in SVGTests. r=jwatt draft
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 29 Mar 2018 20:45:31 +1100 - rev 776497
Push 104891 by nnethercote@mozilla.com at Tue, 03 Apr 2018 07:30:23 +0000
Bug 1449883 - Use `nsStaticAtom* const` instead of `nsStaticAtom**` in SVGTests. r=jwatt MozReview-Commit-ID: JBqaxfrRNCn
cefa834b5f2528cf742ee819181ad3cc2f964c13: Bug 1449883 - Use `nsStaticAtom* const` instead of `nsStaticAtom**` in nsSVGEnumMapping. r=jwatt draft
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 29 Mar 2018 20:45:28 +1100 - rev 776496
Push 104891 by nnethercote@mozilla.com at Tue, 03 Apr 2018 07:30:23 +0000
Bug 1449883 - Use `nsStaticAtom* const` instead of `nsStaticAtom**` in nsSVGEnumMapping. r=jwatt MozReview-Commit-ID: DRCUIaHY5SX
666b6f038a50e7c5635d291de38e82335445d560: Bug 1449883 - Use `nsStaticAtom* const` instead of `nsStaticAtom**` in nsSVGElement.h. r=jwatt draft
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 29 Mar 2018 20:45:24 +1100 - rev 776495
Push 104891 by nnethercote@mozilla.com at Tue, 03 Apr 2018 07:30:23 +0000
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
f2a0bdbb4c5179dd396476263e6a6b57adb13360: Bug 1449827 - Optimize static atom use in nsTreeSanitizer. r=hsivonen draft
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 29 Mar 2018 15:51:39 +1100 - rev 776494
Push 104891 by nnethercote@mozilla.com at Tue, 03 Apr 2018 07:30:23 +0000
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
b9d157b2deb68f4d9aee94bdcff6737caf4336ba: Bug 1449827 - Introduce a typedef `AtomsTable` within nsTreeSanitizer. r=hsivonen draft
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 29 Mar 2018 15:51:39 +1100 - rev 776493
Push 104891 by nnethercote@mozilla.com at Tue, 03 Apr 2018 07:30:23 +0000
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
fa8a152364fb343880f912afed2fa34aaa27aa89: Bug 1449827 - Use `nsStaticAtom* const` instead of `nsStaticAtom** const` in nsTreeSanitizer. r=hsivonen draft
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 29 Mar 2018 15:51:39 +1100 - rev 776492
Push 104891 by nnethercote@mozilla.com at Tue, 03 Apr 2018 07:30:23 +0000
Bug 1449827 - Use `nsStaticAtom* const` instead of `nsStaticAtom** const` in nsTreeSanitizer. r=hsivonen MozReview-Commit-ID: 4tk4BHbEpdt
9111840008a1707bfabc031a66612436d71135b0: Bug 1449395 - Remove nsStaticAtomSetup. r=froydnj
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 29 Mar 2018 11:48:18 +1100 - rev 776491
Push 104891 by nnethercote@mozilla.com at Tue, 03 Apr 2018 07:30:23 +0000
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
554acd814741bf777b6312b027fb9108c97d0c1b: Bug 1449395 - Remove unnecessary nsStaticAtom.h includes. r=froydnj
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 29 Mar 2018 09:08:54 +1100 - rev 776490
Push 104891 by nnethercote@mozilla.com at Tue, 03 Apr 2018 07:30:23 +0000
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
901d8e696721e4ba686d3efc7295b7134f811910: Bug 1449087 - Use Servo data to back @font-face rule. r?emilio draft
Xidorn Quan <me@upsuper.org> - Tue, 03 Apr 2018 17:01:51 +1000 - rev 776489
Push 104890 by xquan@mozilla.com at Tue, 03 Apr 2018 07:23:49 +0000
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
3d427133ccb8975163b4459af57b5d96ef54c93e: Bug 1450315 - Remove document.allowUnsafeHTML. r=bz draft
Johann Hofmann <jhofmann@mozilla.com> - Sat, 31 Mar 2018 10:27:19 +0200 - rev 776488
Push 104889 by jhofmann@mozilla.com at Tue, 03 Apr 2018 07:17:11 +0000
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
6d3811accd7605f311a83a76eb56e05c6802c531: Bug 1450617: No need to ResolveTag to disable first-line on fieldsets. r?bz draft
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 02 Apr 2018 05:52:57 +0200 - rev 776487
Push 104888 by bmo:emilio@crisal.io at Tue, 03 Apr 2018 07:00:14 +0000
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
cb6598552b9b0437858b695f93808d56b7cb53e6: Bug 1450617: Remove resolved namespace id and tag from FCItems. r?bz draft
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 03 Apr 2018 08:51:38 +0200 - rev 776486
Push 104888 by bmo:emilio@crisal.io at Tue, 03 Apr 2018 07:00:14 +0000
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
0cc08cd95ef5821d37768bd14567dfe67047bda0: Bug 1450617: Only allow extending from / to XUL elements. r?bz draft
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 03 Apr 2018 08:37:16 +0200 - rev 776485
Push 104888 by bmo:emilio@crisal.io at Tue, 03 Apr 2018 07:00:14 +0000
Bug 1450617: Only allow extending from / to XUL elements. r?bz MozReview-Commit-ID: JaFKQDkLGgw
944db0ad9b251c109966f1236e6603f92101a4c6: Bug 509958: Unprefix :-moz-selection. r?dbaron,xidorn draft
Emilio Cobos Álvarez <emilio@crisal.io> - Sun, 25 Mar 2018 17:31:55 +0200 - rev 776484
Push 104888 by bmo:emilio@crisal.io at Tue, 03 Apr 2018 07:00:14 +0000
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
974eaa92c3b13af442ff5162e26edfcc870a9195: Bug 1339656: [css-align] Another pass of fixing align shorthand serialization. r?mats draft
Emilio Cobos Álvarez <emilio@crisal.io> - Sat, 31 Mar 2018 02:37:39 +0200 - rev 776483
Push 104888 by bmo:emilio@crisal.io at Tue, 03 Apr 2018 07:00:14 +0000
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
e3ba89c4ddfb875d26b9e22353107f4d453f46f0: Bug 1303605: Make LazyFC assertions actually hold. r?bz draft
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 29 Mar 2018 14:04:40 +0200 - rev 776482
Push 104888 by bmo:emilio@crisal.io at Tue, 03 Apr 2018 07:00:14 +0000
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
321c402d794fb2414bcbc2b84b632560f9df820e: Bug 1303605: Remove the undisplayed maps. r?bz,mats draft
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 29 Mar 2018 03:49:26 +0200 - rev 776481
Push 104888 by bmo:emilio@crisal.io at Tue, 03 Apr 2018 07:00:14 +0000
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
a1360f358cf4c664011b0b2ea6ab3dbdb66c5a59: Bug 1420680: Remove the user font cache generation, which is also unused now. r?jfkthame draft
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 23 Mar 2018 18:09:09 +0100 - rev 776480
Push 104888 by bmo:emilio@crisal.io at Tue, 03 Apr 2018 07:00:14 +0000
Bug 1420680: Remove the user font cache generation, which is also unused now. r?jfkthame MozReview-Commit-ID: HuQg4RopOmX
c0e4f4179159af350e1ed22162bee13b37d96f6e: Bug 1420680: Remove the mechanism to buffer CSP violations. r?bz draft
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 23 Mar 2018 16:11:52 +0100 - rev 776479
Push 104888 by bmo:emilio@crisal.io at Tue, 03 Apr 2018 07:00:14 +0000
Bug 1420680: Remove the mechanism to buffer CSP violations. r?bz With the previous patch it's unused. MozReview-Commit-ID: 4EKufeNu0Jz
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip