Historically, Gecko implemented the behavior allowed by CSS2 whereby a floated ::first-letter is "boxed"
tightly around the glyph shape, rather than using constant font-ascent and -descent metrics which may
leave a lot of blank space depending whether the character has any ascender/descender or not.
However, neither webkit nor blink do this, which leads to webcompat pain when sites are constructed
assuming their behavior.
Eventually, I think we should ideally reimplement ::first-letter entirely at frame-construction time,
rather than during reflow. But in the interest of minimizing risk here, and making it easy to flip
between our existing "legacy" behavior and the new "compatible" behavior, this patch leaves the
overall implementation unchanged and just alters the metrics used for the resulting first-letter
frame.
This patch creates an integer pref layout.css.floating-first-letter.tight-glyph-bounds to allow us
to choose between three behaviors:
1: Use tight glyph bounds, and ignore line-height; the baseline of the floated letter automatically
adjusts to wrap text around the "ink box" of the glyph. This is the existing Gecko behavior.
0: Don't use tight glyph bounds, respect line-height: the floated letter acts like a normal <span>
with float positioning; baseline position and vertical size are based on font metrics but not
the specific shape of the individual glyph. This gives a similar result to webkit/blink.
-1: Automatically choose between (1) and (0) based on heuristics to try and detect whether the page
was written with the webkit/blink behavior (0) in mind; specifically, if there is a line-height
of less than 1em, or a negative block-start margin, we assume the author was trying to eliminate
excess blank space that behavior (0) tends to produce, and so we use that model.
Initially, this patch leaves the behavior unchanged for Beta/Release builds, but enables option -1 (use
heuristics to choose which layout model to apply) on Nightly so we can see how that works in practice.
Differential Revision: https://phabricator.services.mozilla.com/D165008
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
Before this patch, we implicitly invoke the default constructor for this
member-var, and then immediately stomp on the results with a reassignment.
This patch avoids that unnecessary usage of the default constructor, saving
ourslves a bit of work and getting this member-var more directly into a
fully-initialized/valid state.
Differential Revision: https://phabricator.services.mozilla.com/D159903
Before this patch, we had two `checkVisibilty` methods on the
nsISelectionController interface, backed by several layers of implementation,
ultimately backed by a single function on nsTextFrame (which didn't actually
do anything meaningful with any of the parameters).
As it turns out, this API only had one caller, in HTMLEditUtils.cpp.
This patch converts that caller to directly query nsTextFrame (if the given
node's primary frame is indeed a nsTextFrame). The direct function-call is
renamed to HasVisibleText(), to be a bit clearer about it being text-specific
and also to avoid confusion with the (unrelated) recently-specified HTML
checkVisibility() API.
With these changes, we can remove the API from the nsISelectionController
interface and its implementations.
This patch also updates the HTMLEditUtils::IsInVisibleTextFrames documentation
(with s/all/any/) to reflect the reality of what the nsTextFrame impl actually
does.
Differential Revision: https://phabricator.services.mozilla.com/D160563
This patch doesn't affect behavior.
The removed const_casts are unnecessary; they're in a non-const function, so
'this' is already a non-const type.
Depends on D160101
Differential Revision: https://phabricator.services.mozilla.com/D160102
As noted in nsTArray.h, "nsTArray, CopyableTArray, AutoTArray [...] are
infallible by default" (unless you explicitly pass mozilla::fallible, and we
don't do that here.)
So, there's no need to check for failure.
Differential Revision: https://phabricator.services.mozilla.com/D160099
This patch doesn't change behavior.
This no-arg constructor only had one inadvertent usage -- it was used to
default-initialize one of ClusterIterator's member-vars, just before we
reassign it to something else in the constructor body. (I'm fixing that here
by explicitly constructing that member-var up-front in the init list, rather
than in the constructor body.)
Depends on D159902
Differential Revision: https://phabricator.services.mozilla.com/D159903
This creates the gfx support needed to use alternate palettes, though not yet connected
to the CSS rules/properties to define and access them.
Differential Revision: https://phabricator.services.mozilla.com/D157958
This creates the gfx support needed to use alternate palettes, though not yet connected
to the CSS rules/properties to define and access them.
Differential Revision: https://phabricator.services.mozilla.com/D157958
This creates the gfx support needed to use alternate palettes, though not yet connected
to the CSS rules/properties to define and access them.
Differential Revision: https://phabricator.services.mozilla.com/D157958
This creates the gfx support needed to use alternate palettes, though not yet connected
to the CSS rules/properties to define and access them.
Differential Revision: https://phabricator.services.mozilla.com/D157958
Some sites use text content that consists entirely of whitespace, which can
lead to unexpected rendering in High Contrast Mode - namely, backplating of
invisible characters. This commit adds logic that detects text nodes consisting
entirely of whitespace and reports their text area as 0. This commit also adds
a test for the behavior, and modifies an existing test to reflect the new
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D155248
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
gfxFontCache acquires and releases its mutex during various operations.
In order to keep the state internally consistent, we should only release
the lock after the full operation is complete. This involves moving the
deletion of gfxFont to outside the lock via a temporary discard array.
The expiration state should not be protected by the gfxFont's mutex
since we don't hold it during most operations. Instead we should hold
gfxFontCache's mutex because then we can guarantee the operation is
atomic, particularly when a worker wants a font, and the main thread is
aging the generations.
When a font is returned from gfxFontCache, we now return it already
removed from the tracker, and with its refcount updated. This avoids any
potential races between the expiration timer and a worker accessing the
font, as well as simplying the callers so they don't need to be aware of
addref-ing manually in case the result is to be discarded (so that it
gets readded to the tracker).
Differential Revision: https://phabricator.services.mozilla.com/D151821
gfxFontCache acquires and releases its mutex during various operations.
In order to keep the state internally consistent, we should only release
the lock after the full operation is complete. This involves moving the
deletion of gfxFont to outside the lock via a temporary discard array.
The expiration state should not be protected by the gfxFont's mutex
since we don't hold it during most operations. Instead we should hold
gfxFontCache's mutex because then we can guarantee the operation is
atomic, particularly when a worker wants a font, and the main thread is
aging the generations.
When a font is returned from gfxFontCache, we now return it already
removed from the tracker, and with its refcount updated. This avoids any
potential races between the expiration timer and a worker accessing the
font, as well as simplying the callers so they don't need to be aware of
addref-ing manually in case the result is to be discarded (so that it
gets readded to the tracker).
Differential Revision: https://phabricator.services.mozilla.com/D151821
Since callers want just an effective color to compute whether it's dark,
we simplify the API a bit too.
This makes sure we find the dark background in plain text documents.
Differential Revision: https://phabricator.services.mozilla.com/D151018
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Instead, make the behavior consistent across all <length-percentage>
values (by truncating instead of rounding). This is the already-existing
behavior for calc() and percentages, but with this patch we also apply
it to plain length-flavored <length-percentage> values (this is needed
to avoid regressing things like bug 989802).
Regular <length>s keep rounding, to preserve existing behavior. We can
consider changing that in a follow-up if need be.
Differential Revision: https://phabricator.services.mozilla.com/D143857
This gets done usually in BreakSink::Finish, but we don't do
line-breaking in SVG Text so we need to do this here instead.
Do you know where I could crib a test for this?
Depends on D139964
Differential Revision: https://phabricator.services.mozilla.com/D139965
