Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
The localization file is moved to `content/` to make it more clear that it's not intended to be localised.
For the same reason, no Fluent migration script is included as there are no localised strings to migrate.
Differential Revision: https://phabricator.services.mozilla.com/D155702
The code that bug 1754436 deleted checked to make sure there was a widget for the returned view, but it looks like it's possible in some edge cases to have an open popup that doesn't have a widget (most likely just for a split second). We need a widget to dispatch the event, and if it doesn't have a widget it's not visible so no point in touching it at all anyways.
Differential Revision: https://phabricator.services.mozilla.com/D155819
- remove flag and corresponding warning/counter.
- remove attribute from parsers, but keep the atom since it's
used by TreeSanitizer.
- remove tests for mfrac@bevelled, there is a WPT test to check it's
not supported.
- layout/mathml/tests/test_bug975681.html is removed, its tests are
currently (wrongly) all disabled when the flag is off and equivalent
tests for attributes other than bevelled exist in WPT.
Differential Revision: https://phabricator.services.mozilla.com/D154199
- Remove preference, warning and counter.
- Remove tests checking support for it, or replacing with
equivalent 50% and 300% values.
Differential Revision: https://phabricator.services.mozilla.com/D154198
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
- Remove code for align/denumalign/numalign attributes.
- Remove tests checking support for them.
- Remove warning message and counter.
- numalign/denomalign atoms are not removed, since they
are still used by nsTreeSanitizer.
Differential Revision: https://phabricator.services.mozilla.com/D154197
These frames don't honor overflow in any meaningful way, except for
textarea, where overflow inherits into its editing root.
That style change however should be handled on its own by reflowing
(thus avoiding the reframe).
We need to fix GetDesiredScrollbarSizes, which wasn't accounting for
having scrollbars + overflow: hidden / scrollbar-width: none. Reftests
caught that.
Differential Revision: https://phabricator.services.mozilla.com/D155535
This bug is regressed by Bug 1686603 Part 4 [1]. When the used flex-basis is
'content', the old code computes flex base size by using 'auto' as the main size
in `nsContainerFrame::ComputeSizeWithIntrinsicDimensions()`. The method is for
replaced elements to compute sizes, even if the element has no preferred
aspect-ratio such as an `<svg>` without viewBox nor aspect-ratio property.
However, Bug 1686603 Part 4 made replaced elements without preferred
aspect-ratio uses 'max-content' when computing flex base size. Unfortunately, we
only trigger the replaced elements intrinsic sizing via 'auto' but not via
'max-content', so this patch restores the behavior via emplacing 'auto' in
`styleFlexBaseSize`.
[1] https://phabricator.services.mozilla.com/D101795
Differential Revision: https://phabricator.services.mozilla.com/D155628
Unfortunately this test doesn't run as expected on our CI since macs on our CI
are running normal DPI mode.
I tested this test works properly on my macbook, it fails without the fix in the
previous commit and it passes with the fix.
Differential Revision: https://phabricator.services.mozilla.com/D153688
The glyphs "b" and "c" here have radial gradients with non-[0..1] color stop ranges,
and are compared against versions with equivalent normalized gradients.
Depends on D155080
Differential Revision: https://phabricator.services.mozilla.com/D155472
These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
The glyphs "b" and "c" here have radial gradients with non-[0..1] color stop ranges,
and are compared against versions with equivalent normalized gradients.
Depends on D155080
Differential Revision: https://phabricator.services.mozilla.com/D155472
- Remove script_shift_attributes preference and related test, warning
message and parsing.
- Do not remove subscriptshift/supscripshift atoms, since they are
still needed for nsTreeSanitizer.
Differential Revision: https://phabricator.services.mozilla.com/D154195
The glyphs "b" and "c" here have radial gradients with non-[0..1] color stop ranges,
and are compared against versions with equivalent normalized gradients.
Depends on D155080
Differential Revision: https://phabricator.services.mozilla.com/D155472
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
Use a more precise, grid-specific flag to avoid applying grid stretching
etc, and pass an unconstrained block size instead for baseline alignment
measuring, which will cause us to interpret relative sizes as auto.
This shouldn't cause any behavior change, but is a prerequisite
necessary for bug 1609403 (where we don't always want definite sizes
being ignored in measuring reflows for baseline alignment). It's also a
bit clearer, IMO.
Differential Revision: https://phabricator.services.mozilla.com/D155178
This patch will use the width/height attributes from <source> to override
width/height/aspect-ratio CSS property values of <img> elements.
So basically, we need to introduce an extra nsMappedAttribtue member in
HTMLSourceElement (and it only stores width and height attributes).
And then we use it as an extra declarations (which are generated by
Gecko_GetExtraContentStyleDeclarations()) so we can override the
declarations created from presentation attributes of <img>.
Besides, we need to make sure <img> elements get restyled in the
following cases:
1. width/height attributes is changed in <source> elements
2. <source> is inserted as a <picture>'s child
3. <source> is removed from the child list of <picture>
4. <img> is inserted as a <picture>'s child
5. <img> is removed from the child list of <picture>
We make the responsive source synchronously get updated in the previous patch,
so now we can just restyle the image when updating its responsive source.
Note: We fix the reflection of percentages for width/height attributes in
the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D152586
The ColorSchemeMode::Preferred change doesn't make a difference (that
is, always use the preferred one), since when we only propagate from
top's embedder the embedder is chrome, which always has the preferred
color-scheme.
Differential Revision: https://phabricator.services.mozilla.com/D154931