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
This reverts the change to make ideographic space trimmable, because of unintended impact on line
breaking and measurement in other cases. We'll need a more carefully targeted fix for the original
issue in bug 1862249, as well as better test coverage when landing a new patch there.
(Given that we've had multiple regression reports about this, I think we should uplift the backout
to 122. We could even consider it for a 121.x dot-release if one happens, as it's just reverting
to longstanding behavior here.)
Differential Revision: https://phabricator.services.mozilla.com/D197150
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
Jonathan Kew