This is an alternative version of SetLength to be used for the child of an nsFirstLetterFrame,
when we may need to create continuations in order to separate the first-letter from its
following text.
With this, the intrinsic sizes of first-letter should be computed correctly.
Differential Revision: https://phabricator.services.mozilla.com/D211597
If we're querying the intrinsic widths of a first-letter and its continuation
before they have been reflowed, we need to check the extent of the first-letter
text (similarly to what nsTextFrame::ReflowText does) to avoid measuring too
much of the content using the first-letter styling.
This patch checks the first-letter length during intrinsic size computation,
but does not actually work in most cases because nsTextFrame::SetLength will
bail out if there is not already a next-in-flow frame. The following patch
will address that.
Differential Revision: https://phabricator.services.mozilla.com/D211596
With the pref set to 0 by default, this does not change any existing behavior.
My intention is that a following patch will set it to 2 in Nightly. This will affect
a bunch of reftests, and so test/expectation adjustments will also be needed.
Differential Revision: https://phabricator.services.mozilla.com/D207150
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
Values were static_casted where required. Some functions in WritingModes.h were
rewritten such that bitwise operations aren't being used. Added static_casts to
avoid (debug) build errors from debugging printfs in layout/tables/nsCellMap.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D205510
`nsIFrame::GetCursor()` can never return `Nothing()` after bug 1687239, which
removes `nsPluginFrame`. Therefore `mLastFrameConsumedSetCursor` in
`EventStateManager` can never be true.
Differential Revision: https://phabricator.services.mozilla.com/D200890
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Those callers who using the pointer immediately after getting from
`GetPresShell()` can be replaced with `PresShell()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D199164
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
SetNextContinuation() and SetPrevContinuation() are almost always called
together when setting up a continuation link, but the callers don't call them in
particular order. We should unify them as one method so that it's more
ergonomics and robust, especially when we do more complex work such as caching
continuations. Same reason for SetNextInFlow() and SetPrevInFlow().
We choose to merge the SetPrevContinuation() code into SetNextContinuation() for
the symmetry of SetNextSibling(). (Yes, we don't have SetPrevSibling().)
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D197966
We don't line-break after a hyphen when it occurs between numerals, like in page or date ranges,
preferring to keep the range together as a unit when wrapping text.
However, if the available space is very narrow, e.g. in a small table cell, this may lead to
undesirable overflow. So to try and avoid this, this patch allows an "emergency" line-break
opportunity (similar to what `overflow-wrap: break-word` would do) after the hyphen in such
a case.
This affects a number of existing reftests, but the changes in behavior make us more like
WebKit/Blink (which generally allow a break after hyphen between numerals) in these cases,
so it seems unlikely to lead to webcompat issues; rather, it will help with existing issues
where people assume the content can wrap.
Differential Revision: https://phabricator.services.mozilla.com/D197936
We don't line-break after a hyphen when it occurs between numerals, like in page or date ranges,
preferring to keep the range together as a unit when wrapping text.
However, if the available space is very narrow, e.g. in a small table cell, this may lead to
undesirable overflow. So to try and avoid this, this patch allows an "emergency" line-break
opportunity (similar to what `overflow-wrap: break-word` would do) after the hyphen in such
a case.
This affects a number of existing reftests, but the changes in behavior make us more like
WebKit/Blink (which generally allow a break after hyphen between numerals) in these cases,
so it seems unlikely to lead to webcompat issues; rather, it will help with existing issues
where people assume the content can wrap.
Differential Revision: https://phabricator.services.mozilla.com/D197936
This patch doesn't change behavior.
The APIs that I'm changing here are all indexing into an array that only has 5
entries; it's a bit odd to be using a signed array-index for this, particularly
since the indices all originate from GetUnderlineStyleIndexForSelectionType()
which explicitly returns values 0 through 4 (as enum values).
I suspect we were using signed index because we were using an enum to represent
the values, which was signed-by-default. Let's just explicitly declare the
enum to use an unsigned underlying representation, and then change its
downstream integer variables/params to be unsigned as well.
Conveniently, this lets us simplify the assertions about the index being
in-range, since unsigned values are >=0 by definition.
Differential Revision: https://phabricator.services.mozilla.com/D197754
