We can no longer use direction overrides to create the test vs reference renderings here,
because of how harfbuzz now handles the numeral directionality internally. So it's difficult
to come up with a testcase that verifies the exact rendering of the subtending mark + digit(s)
combinations.
What we can do, though, is verify that a single digit combines with the subtending mark
without affecting its overall width; and that a double-digit number *does* increase the
width. These two conditions are unlikely to both hold unless the rendering is behaving
correctly.
(FWIW, Chrome Canary passes these new test versions, as it also uses a recent harfbuzz;
Safari currently fails, as Core Text doesn't support the subtending marks in the same
way, if at all.)
Differential Revision: https://phabricator.services.mozilla.com/D124902
Turns out my patch above causes some failures because chrome:// channels
don't have cache information, so we conservatively assume they always
expire, which causes some interesting timing issues in a single test.
Fun stuff.
Tweak the code so that SubresourceCacheValidationInfo has the
pre-existing data:// URI special-case and also special-cases chrome://
URIs.
Differential Revision: https://phabricator.services.mozilla.com/D124921
With non-wr cumulative resolution contained the presshell resolution, css transform scales, and so called extra resolution. The extra resolution came about from FrameLayerBuilder code called ChooseScale that sometimes chose to render at a larger resolution so that we didn't have to re-render on every frame for animating scales for example.
Bug 1485834 is responsible for the current code and it looks it was just getting zooming to work at all on android with webrender. It put the presshell resolution into mCumulativeResolution. This would make zooming work as before this mCumulativeResolution would be 1. This is because mCumulativeResolution came from the ContainerParameters, which are an implementation detail of non-wr that wr didn't have. So it looks like bug 1485834 just used what was handy (the presshell resolution) to get zooming to work.
Making this use GetTransformToAncestorScale means that we are the same as non-wr except for the extra resolution.
I'm not sure that non-wr should have used the extra resolution, I think it would have been better off using GetTransformToAncestorScale as well.
Using the scale from GetTransformToAncestorScale is what several other places do already: CalculateBasicFrameMetrics, and the code to compute our display port rect from the margins data, so this should be more consistent.
More generally speaking, I think that other than the notable exceptions below, mCumulativeResolution only needs to be set to the presshell resolution, and it is okay to include the css transform scale or extra resolution as long as we do apply and un-apply it consistently. Most places that use mCumulativeResolution multiply it in one place and then divide it in another.
The main exception to that is the display port size in the following places:
1. layer pixels computed using mCumulativeResolution are compared against prefs that are in layer pixels in ExpandDisplayPortToDangerZone
https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/gfx/layers/apz/src/AsyncPanZoomController.cpp#4072
2. GetDisplayportAlignmentMultiplier uses layer pixels computed using mCumulativeResolution to determine alignment
https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/gfx/layers/apz/src/AsyncPanZoomController.cpp#3969
3. CalculatePendingDisplayPort sets the final displayport margins in screen pixels computed using mCumulativeResolution
https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/gfx/layers/apz/src/AsyncPanZoomController.cpp#4171
4. GetDisplayPortFromMarginsData computes the actual displayport rect we use for painting using GetTransformToAncestorScale
https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/layout/base/DisplayPortUtils.cpp#296
Ideally this should match how we calculate the margins in CalculatePendingDisplayPort.
One will note that after this patch extra resolution is always 1 (I plan to remove it in a followup), one might wonder if that is true with webrender. It is true that webrender still has ChooseScale
https://searchfox.org/mozilla-central/rev/a166f59fba89fc70ebfab287f4edb8e05ed4f6da/gfx/layers/wr/StackingContextHelper.cpp#46
and it uses when it encounters content that it cannot natively render so it is rasterized or recorded in the content process. So content can get rasterized or recorded with extra resolution, however it doesn't make it to the wr side in a structured fashion. The items in question are sent to wr as "images" (blob images) with a rect that is equal to their layout rect, without any transforms, resolution, or extra resolution applied. The "images" themselves do contain the extra resolution but they would be drawn using that non-transformed layout rect, and in this case since they have a transform, that transform would be sent to wr on the stacking context pushed for that transform and then that transform would be applied. Wr would not except apz to know about this extra resolution and would not expect values it gets from apz to include this extra resolution.
Now inside wr it could also do something similar where it renders at a resolution that differs from the presshell resolution + css transform scale, but that too would have to be completely internal to wr and it could not expect anyone outside of wr to know about.
The other thing that simplifies this is that the only scrollframe that can have resolution (root content doc root scroll frame) cannot also be transformed. This means that when we are actually managing the zoom (on the rcd-rsf) we never have a css transform scale. And for subframes, other than the displayport sizing, we mostly just multiply and divide by cumulative resolution so it's specific value isn't that important.
Differential Revision: https://phabricator.services.mozilla.com/D124905
With a very simple tweak to SheetLoadDataHashKey::KeyEquals we should
get the same kind of caching but in a much simpler way.
Differential Revision: https://phabricator.services.mozilla.com/D124807
Turns out my patch above causes some failures because chrome:// channels
don't have cache information, so we conservatively assume they always
expire, which causes some interesting timing issues in a single test.
Fun stuff.
Tweak the code so that SubresourceCacheValidationInfo has the
pre-existing data:// URI special-case and also special-cases chrome://
URIs.
Differential Revision: https://phabricator.services.mozilla.com/D124921
This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
The specifics of how this is going to work are still getting spec'd /
discussed in https://github.com/w3c/csswg-drafts/issues/6576, but this
allows DevTools to work fine and the feature to be complete enough for
Nightly experimentation (with the other in-flight patches).
Otherwise devtools crashes when trying to inspect pages that use them.
Differential Revision: https://phabricator.services.mozilla.com/D124656
This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
A UAX29 compatible word breaker (like ICU4C) treat the end of text as a
word break opportunity (rule WB2 [1]), but currently lwbrk word breaker
doesn't.
The motivation of this patch is to make `WordBreaker::Next()` closer to
a UAX29 compatible one (at least for English text), and see if the
callers need to change. This should make the future integration of ICU4X
segmenter easier.
The only caller of WordBreaker::Next() is ClusterIterator's constructor.
This patch shouldn't change its behavior because we've already manually
assigned a word break point at the end of the line when `aContext` is
empty and `aDirection` is -1. This patch generalizes it to all
conditions.
Also, update TestPrintWordWithBreak() so that the result string makes
more sense.
[1] https://www.unicode.org/reports/tr29/#WB2
Differential Revision: https://phabricator.services.mozilla.com/D124304
Windows 11's Snap Layouts feature generates a window of layout options when the maximize window button is moused over. This requires the WM_NCHITTEST message to handle hit detection for the button. Since WM_NCHITTEST messages are very common, although we limit them to no more than every 50ms, we don't want to do a full hit test each time. Instead, we cache the maximize button rect in the widget when it is positioned during layout.
Differential Revision: https://phabricator.services.mozilla.com/D123982
It's interesting case, and it perhaps should be tested in WPT for web-compat.
Chrome 93 passes all tests in the new WPTs, but Gecko fails in the cases of
related to focus (i.e., `execCommand` and user input).
Differential Revision: https://phabricator.services.mozilla.com/D124725
Text is the exception, where clipping the WR commands to the paint rect can let us reduce the size sent.
We want to avoid this when doing fallback painting, since we don't want to have to track paint rect changes for invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D124589
WebRender prefers to know the full bounds of the primitive, since it makes invalidation easier (and doesn't increase the size of the commands we send).
Differential Revision: https://phabricator.services.mozilla.com/D124588
Text is the exception, where clipping the WR commands to the paint rect can let us reduce the size sent.
We want to avoid this when doing fallback painting, since we don't want to have to track paint rect changes for invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D124589
WebRender prefers to know the full bounds of the primitive, since it makes invalidation easier (and doesn't increase the size of the commands we send).
Differential Revision: https://phabricator.services.mozilla.com/D124588
Matt Woodrow
Hiroyuki Ikezoe
Jonathan Kew
Emilio Cobos Álvarez
Tetsuharu Ohzeki
Cristian Tuns
Timothy Nikkel
Sandor Molnar
Ben Hearsum
Sebastian Hengst
Ting-Yu Lin
Cosmin Sabou
David Parks
Nika Layzell
Masayuki Nakano
Marian-Vasile Laza
Iulian Moraru