We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
It will generate a warning and is useless as explained in the code comment.
Differential Revision: https://phabricator.services.mozilla.com/D46626
--HG--
extra : moz-landing-system : lando
We need to distinguish between the out-of-process iframe is totally invisible and
the given nsIFrame is not in out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D46553
--HG--
extra : source : fc785139655e3d22d681f1419bd4c80f93460f0e
`image-short.png` never exists in the first place when this test was
introduced, so the intermittent happens when the test file shows a
broken image icon and the reference file without, or the other way
around.
I believe the `<img>` is served as a monolithic element to overflow
`<div class="short">`. Use an empty src should suffice.
Differential Revision: https://phabricator.services.mozilla.com/D46640
--HG--
extra : moz-landing-system : lando
We need to distinguish between the out-of-process iframe is totally invisible and
the given nsIFrame is not in out-of-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D46553
--HG--
extra : moz-landing-system : lando
This is in the interests of allowing the frontend team to experiment with
switching from XUL grid to CSS grid, without inadvertently changing the
display values for the grid items via css-grid-item blockification.
This patch's new pref is not expected to remain in the codebase for long.
We're just adding it so that the behavior remains the same by default, because
we do currently have some XUL code that inadvertently depends on -moz-box
display values being blockified to 'block'. The plan is for folks to remove
that dependency e.g. by adding explicit 'display:block' styling to frontend
code as-needed. After we've done that, we can tentatively flip the pref to true
by default, and then remove the pref entirely.
Differential Revision: https://phabricator.services.mozilla.com/D45258
--HG--
extra : moz-landing-system : lando
Currently, there's no way to tell whether the SIDEWAYS bit is set from
`writing-mode:sideways-*` or `writing-mode:vertical-*; text-orientation:sideways;`.
To be able to tell them apart, split SIDEWAYS bits into VERTICAL_SIDEWAYS
and TEXT_SIDEWAYS. This is needed by my proposed solution in bug 1102175.
Also, provide convenience methods related to sideways writing-mode, and replace
obscure checks in the codebase.
Note that we don't have the use cases to distinguish vertical-rl from
sideways-rl in layout, but for the completeness, IsSidewaysLR() is still
defined.
Differential Revision: https://phabricator.services.mozilla.com/D46321
--HG--
extra : moz-landing-system : lando
In particular: in our frontend code, if we happen to end up with a flex/grid
item with 'display:-moz-box', we want it to take the same sizing codepath as
other flex/grid items, which are all block-level (even though -moz-box is not
exactly block-level itself). Notably, we want to use ComputeSizeFlags::eDefault
for sizing (like we do for real block-level things), because that's necessary
in order for grid items to stretch correctly in their inline axis.
Also: this patch renames "isBlock" to "isBlockLevel" to reflect reality. Its
naming is based on the constant NS_CSS_FRAME_TYPE_BLOCK, which in fact is not
specific to 'display:block' but in fact is for frames that are "block-level in
normal flow" (which I think in practice means block-level and not
out-of-flow). That is documented here:
https://searchfox.org/mozilla-central/rev/7531325c8660cfa61bf71725f83501028178cbb9/layout/generic/ReflowInput.h#51
Differential Revision: https://phabricator.services.mozilla.com/D46539
--HG--
extra : moz-landing-system : lando
Now that we count them, I think we should do this.
This property is pretty painful for various reasons:
* It's a pretty awkward non-standard property.
* Has a pretty short name, so people use it instead of the standard
alternatives.
* We cannot really even implement it easily anyhow, without breaking a whole
bunch of stuff, because pages do things like:
```
myelement {
zoom: 0.5;
-moz-transform: scale(0.5);
transform-origin: 0 0;
}
```
For now this is only recorded when CSS use counters are enabled (Nightly for
now), but I want to change it once bug 1578661 is in central.
The hope is that this warning slightly raises awareness of this property not
being standard. You get a CSS parsing error in the console, but those are
usually too noisy and disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D46430
--HG--
extra : moz-landing-system : lando
Also causes removing a pref to take effect immediately, and prevents
losing all color pref overrides when the theme changes.
Differential Revision: https://phabricator.services.mozilla.com/D44416
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
This is to avoid skip-ink problems with fonts that leave the OpenType field at zero,
which is unlikely to ever be what is really wanted. Authors can still avoid the clamp by
explicitly using text-underline-offset:from-font.
Differential Revision: https://phabricator.services.mozilla.com/D46268
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
properties-db.js is patched via `./mach devtools-css-db` after flipping
column-span pref to @IS_NIGHTLY_BUILD@ in StaticPrefList.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D41461
--HG--
extra : moz-landing-system : lando
This bug's main patch seems to have reduced the assertion-count for this test
to 1, at least on some platforms, so let's allow that in the annotation.
Landing on a CLOSED TREE with sheriff permission, to fix orange.
Differential Revision: https://phabricator.services.mozilla.com/D46198
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Delete `td {width: 25%}` and prefixed multi-column properties in
column-box-alignment-rtl.html because they are not needed.
rtl2.html is rtl.html plus `inline-size: 600px` on the column container.
rtl3.html is rtl.html plus `html { writing-mode: vertical-rl; }`.
Similarly, rtl4.html is rtl2.html plus
`html { writing-mode: vertical-rl; }`.
Note: in rtl2-ref.html and re4-ref.html, I added
`box-sizing: content-box` to `table` because `table` defaults to
`box-sizing: border-box`.
Differential Revision: https://phabricator.services.mozilla.com/D44280
--HG--
rename : layout/reftests/columns/column-box-alignment-rtl-ref.html => layout/reftests/columns/column-box-alignment-rtl-2-ref.html
rename : layout/reftests/columns/column-box-alignment-rtl.html => layout/reftests/columns/column-box-alignment-rtl-2.html
rename : layout/reftests/columns/column-box-alignment-rtl.html => layout/reftests/columns/column-box-alignment-rtl-3.html
rename : layout/reftests/columns/column-box-alignment-rtl.html => layout/reftests/columns/column-box-alignment-rtl-4.html
extra : moz-landing-system : lando
Since column-contents' positions are moved, we need to fix ColumnSet's
overflow areas as well.
Differential Revision: https://phabricator.services.mozilla.com/D44279
--HG--
extra : moz-landing-system : lando
This required replacing nsDisplayListBuilder::mSVGEffectsBuildingDepth with
a stack of the SVG effects frames that we're currently building inside.
Depends on D46063
Differential Revision: https://phabricator.services.mozilla.com/D46064
--HG--
extra : moz-landing-system : lando
When we call nsContentUtils::IsPatternMatching, we swallow JS engine errors
unconditionally returning true.
This is bad, because if it happens in one of the value sets that arguably
shouldn't change the state of the element, we end up returning an arbitrary
value (true) which may or may not match the previous state of the element.
Handle error explicitly instead, by not updating the state.
Differential Revision: https://phabricator.services.mozilla.com/D45727
--HG--
extra : moz-landing-system : lando
It was added in bug 256624, but -moz-binding is no longer exposed to content so
it doesn't do anything.
Differential Revision: https://phabricator.services.mozilla.com/D45954
--HG--
extra : moz-landing-system : lando
This partially addresses the regression, but not fully. With this patch we don't
maintain shadow trees for nodes that we know won't get rendered.
This works fast in WebKit / Blink because of a bug in their implementation which
doesn't synchronize style attributes, introduced in [1].
You can see this clearly if you click on the bug's test-case and inspect the
<use> shadow trees (there's no style="stroke:orange" whatsoever).
They can kinda get away with it because they don't properly implement SVG 2. In
particular, in Blink / WebKit, the style of the element in the <use> shadow tree
is the style of the referenced element, which means that even if the style
attribute isn't properly synced it's ~ok since it doesn't end up mattering for
styling.
Easiest test-case for the behavior difference is:
```
<!doctype html>
<style>
rect:hover {
fill: green;
}
</style>
<svg width=300 height=300>
<g id="canvas">
<rect fill=red width=100 height=100></rect>
</g>
<g>
<use x=200 href="#canvas"></use>
</g>
</svg>
```
Where Firefox will properly update each square independently when hovered, but
Blink / WebKit won't.
This used to work faster because in this particular test-case we have 3 hidden
<use> elements whose href is the #canvas, which is basically everything.
Before moving to shadow trees we'd do it using anonymous content, and since we
never got a frame we'd never clone the subtree in the first case.
This case was faster before bug 1450250, but this approach makes other cases
slow that were fixed by that bug, like bug 1485402.
So I'll try to optimize shadow tree syncing instead, I guess, but there's no
good reason not to land this in the meantime IMHO.
[1]: f4b022e64b%5E%21/third_party/WebKit/WebCore/svg/SVGElement.cpp
Differential Revision: https://phabricator.services.mozilla.com/D45953
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
DONTBUILD because this is comment-only.
This patch is just addressing a typo in a code comment that was left as a
review nit, which I forgot to address before landing.
Differential Revision: https://phabricator.services.mozilla.com/D45907
--HG--
extra : moz-landing-system : lando
This commit renames nsMathMLElement/nsMathMLElementFactory classes into
MathMLElement/MathMLElementFactory and moves the former into the mozilla::dom
namespace. This is a preliminary step to introduce MathML DOM (bug 1579602).
Code behavior is not changed.
Differential Revision: https://phabricator.services.mozilla.com/D45128
--HG--
rename : dom/mathml/nsMathMLElement.cpp => dom/mathml/MathMLElement.cpp
rename : dom/mathml/nsMathMLElement.h => dom/mathml/MathMLElement.h
rename : dom/mathml/nsMathMLElementFactory.cpp => dom/mathml/MathMLElementFactory.cpp
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
justify-items' initial value is `legacy` and the computed value depends on the
parent's value.
We don't use flex / grid in the scrollbars, so just avoid asserting about this
property.
Differential Revision: https://phabricator.services.mozilla.com/D45673
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
Now that this code path is on its own, we can write more straight-forward code.
Depends on D43799
Differential Revision: https://phabricator.services.mozilla.com/D43800
--HG--
extra : moz-landing-system : lando
The number of rows for the select dropdown can't be calculated in the content process because the dropdown has to be rendered in the parent process.
Therefore, we previously set the number of rows to 1 in this case.
That meant that the page up and page down keys only moved one item at a time for a collapsed select control, making them effectively useless.
Instead, set the number of rows to the maximum in this case.
Differential Revision: https://phabricator.services.mozilla.com/D45154
--HG--
extra : moz-landing-system : lando
This is much easier than the existing ResizeReflowIgnoreOverride function, and
this will allow me to avoid flushing if needed (we already kinda do that
already with the "suppressResizeReflow" thing), which in turn allows me to
consolidate a bunch of the logic for resizes.
The function should be much easier to follow:
* Set the new viewport (async, doesn't do any work).
* Invalidate layout as needed due to the viewport change (that is, resize hint
for the root frame, and invalidate isizes if needed). Also async and doesn't
do any reflowing itself.
* Flush layout / do the reflowing all at once. I think we can stop doing this
much more often now, but that's follow-up work.
Depends on D43798
Differential Revision: https://phabricator.services.mozilla.com/D43799
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Repeating/background images may have extra parameters such the stretch
size and tile spacing, that non-repeating images do not require. By
splitting these apart, we can make it easier to infer what we should do
if snapping changes the size of an image primitive, in addition to
reducing the display list size for non-repeating images.
Differential Revision: https://phabricator.services.mozilla.com/D45056
--HG--
extra : moz-landing-system : lando
This is the only short-term fix for now until we fix editor or find a
test-case...
This will keep asserting on Nightly, but the correctness issue it'd show in
release (some pseudo-classes not matching) is better than crashing.
Differential Revision: https://phabricator.services.mozilla.com/D45575
--HG--
extra : moz-landing-system : lando
The rect will be used for calculating the result of the composition of the
remote display item on the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D44419
--HG--
extra : moz-landing-system : lando
If a <details> is a multi-column container, and has a column-span child
inside, aFrame can be ColumnSetWrapper or column-span-wrapper frame (due
to GetInsertionPrevSibling()'s modification). The latter case is handled
by "Situation #5 in WipeContainingBlock(), and can be reproduced by
changing `<article>` tag to `<details>` in
testing/web-platform/tests/css/css-multicol/multicol-span-all-dynamic-add-005.html
In any case, aFrame might end up in a frame generated by the <details>
element. I feel the assertion to check frame types might not be very
useful. Let's remove it.
Differential Revision: https://phabricator.services.mozilla.com/D45585
--HG--
extra : moz-landing-system : lando
Per the css-contain specification, size contained element must be sized as if
they were empty. The code added to handle size containment shortciruits the
(inline) size calculations, and returns 0. However, an empty <select> element
is rendered as if it contained a and some padding gets added to it by
the UA stylesheet (forms.css). This causes reftest that check that
size-contained <select> elements and empty ones look the same.
This commit fixes this by also shortcircuiting the (inline) size calculations
and returning 0 for empty <select> elements.
Replacing the by a zero width space would not have been enough, since
padding would still be added. It would have been possible to add it in the
inline size calculations of size-contained <select> elements as well, but this
padding serves not purpose when the element is empty, so removing it from there
has no downside, and shortcircuitig both cases is simpler (and marginally
faster) than adding the padding in both cases.
Differential Revision: https://phabricator.services.mozilla.com/D45144
--HG--
extra : moz-landing-system : lando
Also causes removing a pref to take effect immediately, and prevents
losing all color pref overrides when the theme changes.
Differential Revision: https://phabricator.services.mozilla.com/D44416
--HG--
extra : moz-landing-system : lando
Stylo's Gecko wrapper duplicated some logic from the C++ side so
that the Rust compiler would be able to optimize better. Now that
we have xLTO, this kind of manual inlining should not be neccessary
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D43765
--HG--
extra : moz-landing-system : lando
If the <details> has ::first-letter, insertion.mParentFrame may be
modified by GetInsertionPrevSibling(), and points to nsFirstLetterFrame.
Fortunately, nsFirstLetterFrame's content is the details element. We can
check the content to determine if reframing the <details> is needed.
Also, add a reftest to test that an appended text should apply styles in
details::first-line.
Differential Revision: https://phabricator.services.mozilla.com/D45454
--HG--
extra : moz-landing-system : lando