Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Although I haven't been able to reproduce the reporter's OOM crash here, I hope this will avoid
the issue; it certainly improves performance characteristics in my local build.
On the example here, my laptop happily scrolls the text field at 60fps when nothing is selected;
but if the text is selected it can only manage around 40fps, because we lose the clipping
optimization here.
With this change, it maintains 60fps regardless of whether the text is selected (or text-shadow
is present), and memory footprint is substantially reduced.
Differential Revision: https://phabricator.services.mozilla.com/D171318
Before, there existed 3 virtual functions that calculated baselines:
- `GetLogicalBaseline`
- `GetVerticalAlignBaseline`
- `GetNaturalBaselineBOffset`
Each of them had slightly different behaviours:
- `GetLogicalBaseline` would synthesize a baseline if there is no baseline.
Others would simply return `false`.
- `GetNaturalBaselineBOffset` requires the caller to pick which of first/last
baseline to calculate. Others pick on on their own.
- `GetNaturalBaselineBOffset`'s result can be either offset from border box
start/end edge, depending on the caller-supplied baseline. Others always
return offset from border box start edge.
Now:
- `GetNaturalBaselineBOffset` is the sole virtual function.
- `GetLogicalBaseline` exists to support its use, with 2 virtual helper functions:
- `SynthesizeFallbackBaseline` to generate a baseline for elements that
doesn't have one.
- `GetBaselineSharingGroup` to preserve the default baseline picking behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D167990
With this, the old SelectionIterator that expects a per-character array of
SelectionDetails pointers is no longer used anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D170588
This significantly improves performance and reduces memory usage when painting a very long textframe
with some or all of the text selected.
Differential Revision: https://phabricator.services.mozilla.com/D170530
For ToResolvedValue implementation purposes we wouldn't need to split
out the vertical / font / line-height arguments and we could just pass
around the ComputedStyle, but the lh unit would need that distinction,
(because computing lh on font properties should use the parent style).
Differential Revision: https://phabricator.services.mozilla.com/D168705
The WR text bounds are just "ink overflow without shadows", so save some
work and memory when we don't have shadows anyways.
Differential Revision: https://phabricator.services.mozilla.com/D169573
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
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
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
