Almost forgot to do this. This is in case we need to revisit this for
regressions in the future and the tests are not available online. Never know
when they might come in handy again.
It turns out part 10 was actually needed, but Bug 1449838 had a significantly
better version of what that code does that was easy enough to backport to what
we have. As far as I can tell, this passes the relevant reftests now.
My previous fix apparently only worked with GCC 7. Having that return at the
end doesn't seem to hurt anything on Windows, so I see no reason to ifdef it.
I don't remember where I heard this, but I vaguely remember hearing that
ending a function without a return statement may be undefined behavior that
differs between compilers and operating systems. If so, that would explain why
this has behaved so differently across platforms and compilers.
The issue is that select elements may contain some non-Latin characters that
need extra block-size to display than the one line-height calculated by using a
Latin font spec in the style.
Before this patch, when a control has an unconstrained block-size, we set
the element's block-size to one line-height in Reflow(), which is intended to
properly initialize `BlockReflowInput::mMinLineHeight` since it uses
`line-height:-moz-block-height`.
However, this simply prevents the display from choosing a larger block-size
after the reflow occurs. Previously, this discrepancy was absorbed by the extra
padding present to make select elements the same intrinsic size as buttons, but
since we did away with that, we're losing the extra space and the font glyphs
get clipped.
This patch fixes the issue by carrying the computed line height over to the
element's display so that its computed block-size is still unconstrained.
This way it can accommodate taller characters in the display text.
After this patch, a <select><option> containing non-Latin characters should have
the same block-size as <button>, and no characters should be clipped.
To better distinguish the calculation of line height (still present with args)
and simply getting the line height without args, it's now called GetLineHeight()
This also introduces `mLineHeight` to cache specifically calculated line heights
that aren't "auto" (which is a magic value), and it opens up the possibility to
override it in Part 7.
This doesn't change behavior by default but allows authors to remove the padding
previously enforced to align with focus ring padding, if they wish to.
Extra padding was created for a prospective -moz-focus-inner ring.
We now just size that ring the same as the content frame, inflated by its CSS
padding.
This allows us to use a greater rendering depth for exceedingly-deep DOM trees
in layout, better matching what mainstream browsers are capable of. Note that
for 32-bit Windows the stack size MUST be set to larger than the default or Bad
Things Will Happen™ - we use 1.5 MB for this as a carefully-tuned value.
This needs to be capped specifically for JS use because some JavaScript
obfuscators deliberately trigger stack overflows and would lock up the browser
otherwise as long as there's still stack space to abuse. For web compatibility
we therefore limit this to 2MB in JS only (3x for ASAN) while still allowing
a greater depth for the layout engine.
Backported from Mozilla bug 1472602.
Didn't include the change in StickyScrollContainer.cpp because it breaks
linking to libxul.so in the end. It's not important anyway.
I could have done this through a CSSLoader to allow all CSS unit quirks but
I wasn't planning to start passing around document and element references
everywhere, so instead just did it manually by accepting numbers/floats in
addition to pixel and percent.
This attempts to get the first non-whitespace token, which if exists, continues with previous behavior of parsing the margin string. Otherwise, if the specified margin string is empty or consists only of whitespace characters, is interpreted as zero length.
IntersectionObserver is the only consumer of the `ParseMarginString` method, as far as I can tell, so this should not affect anything else.
Note: For some reason, Firefox and Chrome treat the unitless zero length as invalid, while with this change, we do not change existing behavior in that regard and continue to accept that value.
We have four entry points that deal with the parents of display:none/ display:contents content. These are the functions for setting, changing, getting and removing a style context. Or more specifically:
GetStyleContextInMap called by GetDisplay[None|Contents]StyleFor
SetStyleContextInMap called by RegisterDisplay[None|Contents]StyleFor
ChangeStyleContextInMap called by ChangeRegisteredDisplay[None|Contents]StyleFor
UnregisterDisplay[None|Contents]StyleFor okay, this is actually two functions, but they act as a pair
This change makes all these functions call GetApplicableParent up front and act on and pass around the parent that it returns. This is so that throughout the code we are always handling the parent that will be used as the key in the UndisplayedMap entry. This is necessary so that all the code that sets/gets the 'MayHaveChildrenWithLayoutBoxesDisabled' bit on/from an nsIContent object is using the same object, otherwise everything breaks down.
Partially based on part 2 of https://bugzilla.mozilla.org/show_bug.cgi?id=1367214
This introduces the `ParentForUndisplayedMap` helper method to reduce duplication in terms of getting the parent and asserting parent existence.
Partially based on parts of https://bugzilla.mozilla.org/show_bug.cgi?id=1341083
Changing to vector makes manipulating display list items more risky.
This is to make sure we don't inadvertently end up with duplicates in
the list of display items avoiding double-free scenarios.
This removes the need to keep the `flex-basis` handling code of the ComputeSize* functions in sync since they both call the same function now for this purpose.
