Calling IsLink ignores whatever state we have for aTreeMatchContext and will trigger an assertion if aTreeMatchContext.mForStyling is false. This also adds a comment about what that line effectively does.
What happens here if aListHead is an empty selector list:
(1) next selector group is parsed and continues to the next iteration if it's empty or invalid
(2) if we're a forgiving selector list and aListHead is empty, replace it with the selector group that we've just parsed
(3) step 1 ignores invalid/empty, so we assert that step 2 should never have an empty selector list
This should allow pseudo-classes that accept selector lists to properly handle complex selectors. `:visited` is also matched inside selector lists.
A previous iteration of this commit had incorrect matching behavior when called from `RestrictedSelectorListMatches`.
This makes it clear that we're accessing a selector list (nsCSSSelectorList), which is different from the selectors (nsCSSSelector) contained inside a selector list. Previously, both were confusingly referred to as mSelectors.
This modifies selector list parsing to accommodate being "forgiving". Aliases for the :is selector's former names were also included. Note that the older and prefixed variant `-moz-any` remains unforgiving.
Editor changes caret visibility during drag and drop. But when destroying
editor, we don't restore caret state. So we should restore it when destroying
editor.
Co-authored-by: Makoto Kato <m_kato@ga2.so-net.ne.jp>
This implements the "clip" attribute value for the "crop" attribute found in XUL label elements. It functions similarly to having the text-overflow property set to an empty string or "". This shouldn't break previously established behavior as it only adds a new value to be checked.
The behavior of the "none" attribute value in the documentation (https://udn.realityripple.com/docs/Archive/Mozilla/XUL/Attribute/crop) is incorrect. The "none" attribute value literally means "don't crop anything" if you'd check the code and is also equivalent to not setting the "crop" attribute at all. This has always been the case since Firefox 2 (earliest version I checked) and apparently, this section of the documentation was copied verbatim from XULPlanet without even checking if it's correct.
Based on selected bits of M-C 1461708:
- EventStateManager::CheckForAndDispatchClick() to early-return style
- split EventStateManager::CheckForAndDispatchClick() into:
EventCausesClickEvents, PostHandleMouseUp, DispatchClickEvents
- Move implementation of UIEvent::GetRangeParent() and UIEvent::RangeOffset() to nsLayoutUtils
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.
FranklinDM
Job Bautista
Moonchild
Martok
roytam1
Jeremy Andrews