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
The wpt will be updated in
https://github.com/web-platform-tests/wpt/pull/18866.
Besides, there are some other test cases use text-decoration, so we
have to update them as well. The rule is: if the test case is not related to
old `text-decoration` longhand, we use `text-decoration-line` instead.
If the test case is for testing the change of `text-decoration` from
longhand to shorthand, we should use the correct serialization.
Differential Revision: https://phabricator.services.mozilla.com/D44909
--HG--
extra : moz-landing-system : lando
This is required due to different backends being used for SVG images and canvas.
Differential Revision: https://phabricator.services.mozilla.com/D44154
--HG--
extra : moz-landing-system : lando
Helps support migrating from XUL DOM to an HTML DOM structure. I attempted
to remove the early return when the root element is not a XUL element, but
it appears setting the transparency on a non XUL root is still broken
(test widget/tests/test_mouse_scroll.xul started failing on windows).
Differential Revision: https://phabricator.services.mozilla.com/D40734
--HG--
extra : moz-landing-system : lando
Frames split by column-span are linked together by non-fluid
continuations. We want GetLogicalSkipSides() to recognize that. The
documentation in nsIFrame::GetLogicalSkipSides() already
uses *continuation* rather than *in-flow*, so no need to adjust the
wording.
However, after patching GetLogicalSkipSides(), the first column-content
after a column-span split starts to skip the block-start side because it
has a previous continuation. We want the content in the first column to
consider applying its block-start margin. Hence the modification in
BlockReflowInput's constructor. (Note that the first column-content is
always a block-start margin-root, which is fixed in the previous part.)
This is necessary to avoid breaking
testing/web-platform/tests/css/css-multicol/multicol-span-all-margin-bottom-001.xht
In multicol-span-all-children-height-006.html, add "margin-top: 1em;" to
the container to expose the bug if we still check GetPrevInFlow() rather
than GetPrevContinuation() when computing applyBStartMargin in
nsBlockFrame::ReflowBlockFrame().
Differential Revision: https://phabricator.services.mozilla.com/D43905
--HG--
extra : moz-landing-system : lando
nsBlockDebugFlags.h defines NOISY_BLOCK_DIR_MARGINS, which is used in
nsBlockFrame. Include it in nsBlockReflowContext.cpp so that when
NOISY_BLOCK_DIR_MARGINS is defined, the log is printed in
nsBlockReflowContext.cpp as well.
Remove unused NOISY_MAX_ELEMENT_SIZE and REALLY_NOISY_MAX_ELEMENT_SIZE.
Differential Revision: https://phabricator.services.mozilla.com/D43903
--HG--
extra : moz-landing-system : lando
We can end up in here from a style worker thread. But that's safe since
we only read data from the FontFaceSet, and the main thread is blocked
so writes can't happen underneath us.
Differential Revision: https://phabricator.services.mozilla.com/D44589
--HG--
extra : moz-landing-system : lando
To prevent these tests depending on Bug 1102175 to pass because they
specify "direction" or "writing-mode" on <body>, replace <body> with
<main>. This patch doesn't change the meaning of the tests.
Except for shape-outside-margin-box-border-radius-008.html, which is
modified manually, all the other files are modified by the follow Python
3 script.
```
import fileinput
import glob
open_tag_before = '<body class="container">'
open_tag_after = '<main class="container">'
end_tag_before = '</body>'
end_tag_after = '</main>'
match_files = 'layout/reftests/w3c-css/submitted/shapes1/*.html'
with fileinput.FileInput(glob.glob(match_files), inplace=True) as f:
found_open_tag = False
for line in f:
if not found_open_tag:
line_open_tag = line.replace(open_tag_before, open_tag_after)
if line_open_tag != line:
print(line_open_tag, end='')
found_open_tag = True
else:
print(line, end='')
else:
# Continue search for end tag
line_end_tag = line.replace(end_tag_before, end_tag_after)
if line_end_tag != line:
print(line_end_tag, end='')
found_open_tag = False
else:
print(line, end='')
```
Differential Revision: https://phabricator.services.mozilla.com/D44942
--HG--
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
This will permit implementation of JSPrincipals::write().
Differential Revision: https://phabricator.services.mozilla.com/D44604
--HG--
rename : dom/worklet/WorkletPrincipal.cpp => dom/worklet/WorkletPrincipals.cpp
rename : dom/worklet/WorkletPrincipal.h => dom/worklet/WorkletPrincipals.h
extra : moz-landing-system : lando
Pruning these meant that `<span><br></span>` wasn't represented in the tree or rendered text at all.
This meant that lines were merged together in NVDA browse mode; e.g. in CI build logs on Gitlab.
The reason we started pruning these is that they were causing invalid line offsets to be returned for affected lines (bug 899433).
This patch also fixes this problem in HyperTextAccessible::FindOffset.
Differential Revision: https://phabricator.services.mozilla.com/D44815
--HG--
extra : moz-landing-system : lando
In the next part, the patch generated by a script removes "-moz" prefix
to all multi-column properties.
However, some of the tests already have standard multi-column properties
specified. To avoid duplicating CSS multi-column rules in these
files (after applying the next part), I manually remove the prefixed
rules beforehand as many as possible.
Differential Revision: https://phabricator.services.mozilla.com/D44869
--HG--
extra : moz-landing-system : lando
Flex containers resolve a main-axis size for each of their flex items, and they
impose this size on the flex items by stomping on the items'
ReflowInput::ComputedISize() or ComputedBSize() data. For cases when we're
stomping on the flex item's block-axis, then this can make us improperly treat
this size as definite (i.e. use it for percent resolution).
The flexbox spec does call out some cases where the item's size *is* supposed
to be considered definite[1], but if we're not in one of those cases, we need
to be careful to treat the size as indefinite even though it's been resolved.
This patch achieves this by:
- adding a flag to FlexItem, which gets set in cases where we know we need to
treat the size as indefinite.
- adding a flag to ReflowInput, which gets set whenever a ComputedBSize is
imposed (if the FlexItem had its flag set).
- adding some code to the ReflowInput percent-resolution codepath to test for
this flag and skip past percent-resolution if it's set.
This patch makes us pass all of the existing testcases in the web-platform-test
"percentage-heights-003.html". This patch also adds a few more subtests
there to exercise cases where the flex container and item have orthogonal
writing-modes.
(Note the XXXdholbert comments in the patch about items being "fully
inflexible" in some cases in order to be treated as having a definite size.
If I were to address that comment here, then we would start failing the
web-platform-test "percentage-heights-005.html", which all browsers currently
pass[2]. Therefore, I'm not adding that restriction at this point.)
[1] https://drafts.csswg.org/css-flexbox/#definite-sizes
[2] https://wpt.fyi/results/css/css-flexbox/percentage-heights-005.html
Differential Revision: https://phabricator.services.mozilla.com/D43705
--HG--
extra : moz-landing-system : lando
This is done by delaying the code within nsFrameLoader::CreateStaticClone until
after the document has been created. The nsFrameLoader is re-discovered using
the subframe BrowsingContext's mEmbedderElement.
Differential Revision: https://phabricator.services.mozilla.com/D44586
--HG--
extra : moz-landing-system : lando
This change was causing issues with images not displaying and iframes not
displaying correctly after multiple print preview calls.
Differential Revision: https://phabricator.services.mozilla.com/D44585
--HG--
extra : moz-landing-system : lando
This is so that SetUseCounter is as cheap as possible.
This is in preparation for hooking the CSS use counters to telemetry. We want
CSS use counters to be fast and be propagated at once to the parent page. This
will make sure to use the same setup as everywhere else.
Differential Revision: https://phabricator.services.mozilla.com/D44645
--HG--
extra : moz-landing-system : lando
Previous commit on this bug bumped up the test from a line-height of 1.5
to 1.8, but that's still not taller than the default widget height on Debian.
But 2.5 does seem to be sufficiently tall to produce a size difference.
Differential Revision: https://phabricator.services.mozilla.com/D44719
--HG--
rename : layout/reftests/forms/input/text/line-height-1.8.html => layout/reftests/forms/input/text/line-height-2.5.html
extra : moz-landing-system : lando
When we had it in the loop, we would continually reduce it, which held the
possibility of bumping it down an epoch due to double imprecision. Now
we only reduce it once, using all rAF callbacks get the same timestamp.
Differential Revision: https://phabricator.services.mozilla.com/D44526
--HG--
extra : moz-landing-system : lando
Most of things will likely be no real change because they ask for the exact frame they want immediately before.
Differential Revision: https://phabricator.services.mozilla.com/D44359
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
That gives the profiler a chance to attach to a newly created content
process. There's no API for waiting for the profiler to be ready in a
just-created process, unfortunately.
Differential Revision: https://phabricator.services.mozilla.com/D43898
--HG--
extra : moz-landing-system : lando
This patch was generated by running each of the scripts in the folder
layout/reftests/w3c-css/submitted/text-decor-3/support/
(This patch also includes a manual edit to reftest.list, to annotate some Win7
fuzziness that was caused by the new choice of font for a set of tests here.)
Differential Revision: https://phabricator.services.mozilla.com/D44258
--HG--
extra : moz-landing-system : lando
Also, adjust the scripts to leave behind a note in each generated HTML file, to
tell the reader that the file is auto-generated.
Differential Revision: https://phabricator.services.mozilla.com/D44257
--HG--
extra : moz-landing-system : lando
DONTBUILD because this is a comment-only change.
Per bug 1481951 comment 6, it seems our behavior was in fact correct even when
the comment was added, and this "// XXX" comment was just due to a
misunderstanding in what was going on in the testcase.
Differential Revision: https://phabricator.services.mozilla.com/D44229
--HG--
extra : moz-landing-system : lando
As noted this changes behavior, but it's unclear per
https://github.com/w3c/csswg-drafts/issues/2328 what behavior is correct, and
our behavior is inconsistent depending on whether there's any percentage
involved.
This matches other browsers so it's pretty low risk I'd say.
The test starts passing without changes to the test, but given the CSSWG issue I
made the test not rely on the optimization.
Differential Revision: https://phabricator.services.mozilla.com/D43754
--HG--
extra : moz-landing-system : lando
SVG Text stuff doesn't support abspos or anything like that, so it's not like it
is useful.
Differential Revision: https://phabricator.services.mozilla.com/D44136
--HG--
extra : moz-landing-system : lando
Most other overrides of nsIDOMEventListener::HandleEvent don't null check
aEvent at all. This method should never be called without an event.
Differential Revision: https://phabricator.services.mozilla.com/D38906
--HG--
extra : moz-landing-system : lando
For developing properties, we will handle them in an other bug.
Besides, I use an iframe for the test because we create a use counter in
the constructor of Document, which use the prefs to decide what kind of
properties we want to record. So, in the test, we have to reload iframe
to make sure we re-create the document, so does the use counter, to make
sure the prefs work properly.
The two prefs affect the css use counters:
1. layout.css.use-counters.enabled: Allocate use counters, and record
non-custom properties.
2. layout.css.use-counters-unimplemented.enabled: Record all unimplmented
properties into the use counters.
If we disable layout.css.use-counters.enblaed, we don't create use counters
object, so layout.css.use-counters-unimplemented.enabled doesn't work,
either.
Differential Revision: https://phabricator.services.mozilla.com/D43860
--HG--
extra : moz-landing-system : lando
In FrameLayerBuilder::ChooseScale we hit this line https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/layout/painting/FrameLayerBuilder.cpp#6124 and aVisibleRect is empty (because every call site except for nsDisplayMasksAndClipPaths::CreateWebRenderCommands (which doesn't need to) passes empty for the size of the bounds) and so the maxScale stays at 4, and we clamp to 4 instead of something 30-50.
The call to ChooseScale in StackingContextHelper::StackingContextHelper is the only place the size of aBounds is ever looked at. And we only ever call ChooseScale if we are passed a mBoundTransform which only nsDisplayTransform does. So this change should be quite safe.
Differential Revision: https://phabricator.services.mozilla.com/D43546
--HG--
extra : moz-landing-system : lando
In FrameLayerBuilder::ChooseScale we hit this line https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/layout/painting/FrameLayerBuilder.cpp#6124 and aVisibleRect is empty (because every call site except for nsDisplayMasksAndClipPaths::CreateWebRenderCommands (which doesn't need to) passes empty for the size of the bounds) and so the maxScale stays at 4, and we clamp to 4 instead of something 30-50.
The call to ChooseScale in StackingContextHelper::StackingContextHelper is the only place the size of aBounds is ever looked at. And we only ever call ChooseScale if we are passed a mBoundTransform which only nsDisplayTransform does. So this change should be quite safe.
Differential Revision: https://phabricator.services.mozilla.com/D43546
--HG--
extra : moz-landing-system : lando
In Bug 1387894 we created a mode for Firefox where it unconditionally clamps all timestamps to 20 microseconds. This happens if you disable privacy.reduceTimerPrecision (which is on by default) and is so we don't inadvertently leak super-high-resolution (nanosec) timestamps.
As part of that patch, we started clamping animation timestamps - which are exempted from privacy.reduceTimerPrecision because it was too difficult to get them working at the time. (We should still fix that though.)
This caused new test failures, and one of those was a comparison between document timelines and the timestamp in requestAnimationFrame. we were not clamping the timestamp in requestAnimationFrame under the logic that it fires in predictable intervals.
However discussions about the WPT change we made to 'fix' the now-broken comparison https://github.com/web-platform-tests/wpt/pull/18172 and https://github.com/web-platform-tests/wpt/pull/18357 showed me that document.timeline is supposed to be slaved to the requestAnimationFrame timestamp (or vice versa.)
The correct fix is therefore to unconditionally clamp the requestAnimationFrame timestamp AND the document.timeline timestamp. In doing so we also start clamping/jittering the requestAnimationFrame timestamp in Resist Fingerprinting mode, so that might cause some new/unexpected behaviors for that mode we should watch out for.
Differential Revision: https://phabricator.services.mozilla.com/D43788
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/70NFnet82cU
This commit introduces a new mathml.xlink.disabled option to disable support
for XLink attributes on MathML elements together with a use counter and
deprecation warning when support is enabled. For now, support is only disabled
in Nighly.
In the past, we relied on custom MathML deprecation warnings but those are
removed here. Corresponding tests for these legacy warning messages are
also removed from test_bug553917.html.
link-1.xhtml is run with XLink support enabled (since it check xlink:href)
while browser_contentAltClick.js is updated to check whether XLink has any
effect on MathML, depending on whether the option is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D43332
--HG--
extra : moz-landing-system : lando
This avoids doing wasted work and sending spurious resize
events if this case would be hit.
In practice, it cannot be hit yet, I think, because
callers do check for this and bail out earlier. But
there's no assertion to that respect so this shouldn't
hurt.
Differential Revision: https://phabricator.services.mozilla.com/D43798
--HG--
extra : moz-landing-system : lando
Depends on D43639
This will avoid applying High Contrast mode colors to devtools documents even when DevTools are loaded in a frame with type=content
This behavior can be disabled by setting devtools.toolbox.force-chrome-prefs to false
Differential Revision: https://phabricator.services.mozilla.com/D43614
--HG--
extra : moz-landing-system : lando
Converted the following to StaticPrefs so that we can easily test variations:
NS_GC_DELAY
NS_SHRINK_GC_BUFFERS_DELAY
NS_FIRST_GC_DELAY
NS_FULL_GC_DELAY
NS_INTERSLICE_GC_DELAY
NS_USER_INTERACTION_INTERVAL
Differential Revision: https://phabricator.services.mozilla.com/D43112
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/5#issuecomment-475506856
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/kl5c87mBlO0
This patch introduces a new preference
mathml.deprecated_style_attributes.disabled in order to disable legacy support
for attributes background, color, fontfamily, fontsize, fontstyle and
fontweight. Note that xlink:href will be handled separately in bug 1575870.
* A new counter and deprecation message is introduced for these attributes.
In nsMathMLElement, the old WarnDeprecated calls are replaced with a single
call to WarnOnceAbout for the deprecate attributes. Notice that for some
reason, the color attribute used to send warning in both ParseAttribute and
MapMathMLAttributesInto.
* sMtableStyles is removed and replaced with a simple comparison.
* sMathML3Attributes is split into two tables: one for script attributes which
will be handled in bug 1548471 and one for style attributes, handled here.
The attributes in this second table is now ignored when the feature flag is
disabled.
* test_bug553917.html is updated so that it no longer checks the old warning
messages for these attributes. New warning messages have been verified
manually.
* Reftests checking support for these attributes are run with the support
enabled.
* Finally, WPT tests are run with the support disabled and a new test
is added to verify that these attributes are no longer mapped to CSS.
Differential Revision: https://phabricator.services.mozilla.com/D43111
--HG--
extra : moz-landing-system : lando
(Given that this was fixed quite a while ago, I didn't actually test
this in the reftest harness prior to the patch, but I did check that the
testcase fails in the browser on Firefox 68 release.)
Differential Revision: https://phabricator.services.mozilla.com/D43644
--HG--
extra : moz-landing-system : lando
Converts browser.tabs.remote.desktopBehavior to a static pref. Updates usages.
Differential Revision: https://phabricator.services.mozilla.com/D42390
--HG--
extra : moz-landing-system : lando
This also fixes some of the issues with -moz-image-region, where we just minted
an auto out of the blue.
Depends on D43472
Differential Revision: https://phabricator.services.mozilla.com/D43474
--HG--
extra : moz-landing-system : lando
This patch changes behavior only if column-span is enabled. It fixes a
lot of fuzzing test cases which will be added in the next part.
It changes the column balancing behavior in the following ways.
1) By using unconstrained block-size to measure the last column in the
first balancing iteration, we can guarantee that mKnownFeasibleBSize
has the correct feasible block-size.
2) Always reflow one more time if the content cannot fit in the
available content block-size. Due to 1), the content (last column)
always returns fully complete in the first balancing iteration even if
it's in an inner column with a constrained available block-size. We need
to reflow again to get the correct *incomplete* reflow status so that
the outer column can create next-in-flows for the inner column.
3) ColumnSet gives up balancing only when ColumnSetWrapper is running
out of block-size. When a ColumnSetWrapper has constrained block-size,
i.e. it's in a fragmentation context like pages or nested columns, we
prioritize fragmenting ColumnSetWrapper over creating overflow columns
within the nsColumnSet.
Differential Revision: https://phabricator.services.mozilla.com/D43128
--HG--
extra : moz-landing-system : lando
Every time I read the code, the name `blockReflowInput` makes me think
the variable is an instance of `BlockReflowInput`, but it is not.
Differential Revision: https://phabricator.services.mozilla.com/D43127
--HG--
extra : moz-landing-system : lando
That is when ColumnSet gives its last ::moz-column-content unbounded
available block-size in the very first balancing iteration.
Note that the last column's available block-size isn't
really *unbounded* yet, but we'll make it happen in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D43126
--HG--
extra : moz-landing-system : lando
Straight-forward addition of the --no-install option for reftest, just like
the existing option for mochitest. For gtest, I alos noticed the mach command
help needed some cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D43299
--HG--
extra : moz-landing-system : lando
See https://github.com/w3c/csswg-drafts/issues/4239
This fixes what is in my opinion one of the biggest issues of scroll anchoring
as specified / currently implemented.
It's trivial to flush layout on a scroll handler and create scroll adjustments,
which in turn would trigger other scroll events to be fired. This situation,
which is what has happened in most of the scroll anchoring regressions I've
fixed, at best gets pages to get stuck in an infinite CPU loop. At worst, it
causes scrolling to be unusable because the page keeps reacting to scroll
events.
An alternative, slightly more elegant but not clear to me if 100% implementable
approach would be bug 1529702.
This should enormously reduce the need for scroll anchoring suppression
triggers[1], I'd think, which in turn would allow me to investigate removing
some of that complexity.
https://drafts.csswg.org/css-scroll-anchoring/#suppression-triggers
The setup to set / unset the boolean is a bit awkward but I couldn't come up
with anything better.
Differential Revision: https://phabricator.services.mozilla.com/D43233
--HG--
extra : moz-landing-system : lando
performAction, performActionOnRow and performActionOnCell are methods of the
nsITreeView interface that are never called. This is to remove these methods.
A comm-central patch will be along shortly.
Differential Revision: https://phabricator.services.mozilla.com/D39273
Some of it was dead code, another was inlining a not very useful function (and
in one case redundant, since EnsureInitialized() happened right after
Refresh()).
Differential Revision: https://phabricator.services.mozilla.com/D43042
--HG--
extra : moz-landing-system : lando
This commit introduces new counters and deprecation warnings for the following
MathML features:
* mathspace names (bug 1575542)
* mathsize names (bug 1548527)
* linethickness names (bug 1548529)
Note: helper parsing functions for mfrac and mpadded are changed to non-static
in order to pass the document parameter needed to log warnings to the console.
Change manually tested with
<math>
<mspace width="thinmathspace"></mspace>
<mpadded width="2thickmathspace"></mpadded>
<mfrac linethickness="thin"><mn>1</mn><mn>2</mn></mfrac>
<mtext mathsize="big">3</mtext>
</math>
Differential Revision: https://phabricator.services.mozilla.com/D42890
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/23
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/wIjm9JjVHNg
This commit introduces a new preference option
mathml.legacy_number_syntax.disabled to disable legacy MathML numbers
(e.g. "1234.") that are not supported by CSS. This feature is now disabled by
default.
* test_bug553917.html is updated to check that such legacy values now cause an
error message to be logged into the console when the feature is disabled.
* Legacy MathML features are now disabled for WPT mathml test in a global
__dir__.ini file. Removing legacy numbers allow to pass
mathml/relations/css-styling/lengths-2.html
Differential Revision: https://phabricator.services.mozilla.com/D42907
--HG--
extra : moz-landing-system : lando
This is consistent with the `order` property anyhow, and allows to simplify some
code.
Negatives are still not parsed, but rust uses a similar representation for all
CSS <integer> values and so should C++.
Differential Revision: https://phabricator.services.mozilla.com/D42912
--HG--
extra : moz-landing-system : lando
Rather than short circuit the refresh driver, this instead only bypasses painting on
Android when WebVR is in immersive mode.
Differential Revision: https://phabricator.services.mozilla.com/D42973
--HG--
extra : moz-landing-system : lando
Removes vsync.parentProcess.highPriority pref and stores BrowserTabsRemoteAutostart() directly into sHighPriorityEnabled.
Differential Revision: https://phabricator.services.mozilla.com/D42962
--HG--
extra : moz-landing-system : lando
The flag's original form `mUnconstrainedHeight` was added in
nsBlockReflowState.h in
e580331b37
Nowadays, we often check available block-size in reflow directly in nsBlockFrame.
Differential Revision: https://phabricator.services.mozilla.com/D42733
--HG--
extra : moz-landing-system : lando
Somehow, updating lz4 from version 1.9.1 to 1.9.2 makes this test reliably pass.
Differential Revision: https://phabricator.services.mozilla.com/D42927
--HG--
extra : moz-landing-system : lando
ReferrerPolicy gets tossed back and forth as a uint32_t and
ReferrerPolicy enum in header file. Expose ReferrerPolicyValues from
webidl file and use consistently in native code.
Differential Revision: https://phabricator.services.mozilla.com/D41954
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/75
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/yEMdIOo4i-0
This commit introduces a new preference option
mathml.mathspace_names.disabled to disable *mathspace names for MathML lengths.
For now, these are only disabled in Nightly builds.
* test_bug553917.html is updated to check that these values now cause an
error message to be logged into the console when mathsize names are used
and the feature disabled.
* mathml-negativespace-ref.html and positive-namedspace.html verify support for
mathspace names, so force running them with the support enabled.
* The reference files for mo-lspace-rspace-2.html, mo-lspace-rspace-3.html,
mo-lspace-rspace.html, op-dict-8.html and op-dict-9.html use explicit
lspace/rspace attributes corresponding to the one read from the operator
dictionary. Instead of running them with mathspace names enabled, use the
equivalent em values from core
https://mathml-refresh.github.io/mathml-core/#operator-dictionary
See https://github.com/mathml-refresh/mathml/issues/75#issuecomment-523016332
* Force WPT tests
mathml/presentation-markup/fractions/frac-linethickness-002.html and
mathml/relations/css-styling/lengths-2.html to be run with the features
disabled and remove corresponding failure expectation.
Differential Revision: https://phabricator.services.mozilla.com/D42643
--HG--
extra : moz-landing-system : lando
Collect telemetry for the number of pending style and layout flush requests per
flush and the number of style and layout flushes per nsRefreshDriver::Tick. A
style flush reports only style requests, but a layout flush reports style and
layout requests since flushing layout implies a style flush also.
Differential Revision: https://phabricator.services.mozilla.com/D40756
--HG--
extra : moz-landing-system : lando
1. Add `this` to the log so that it's easier to debug a nested column
balancing
2. Print the struct fields the same as their names.
Differential Revision: https://phabricator.services.mozilla.com/D42711
--HG--
extra : moz-landing-system : lando
nsBlockFrame already prepares the available block-size for
ColumnSetFrame with ColumnSetWrapper's block-size and max-block-size
applied. (ColumnSet's computed block-size and max block-size is always
unconstrained when column-span is enabled.)
Differential Revision: https://phabricator.services.mozilla.com/D42710
--HG--
extra : moz-landing-system : lando
Before bug 1411422, a ::-moz-column-content has height:100%, so it could
go into this path if ColumnSet's available block-size is unconstrained.
However, after bug 1411422, height:100% was removed for
::-moz-column-content. That is, its computed block-size is
unconstrained, so it can't go into this path. This applies regardless of
whether column-span is enabled or not.
Differential Revision: https://phabricator.services.mozilla.com/D42708
--HG--
extra : moz-landing-system : lando
I replaced the values with -moz-inline-box in the crashtests
rather than removing them. I think they are still valuable
after replacing the display value.
Differential Revision: https://phabricator.services.mozilla.com/D42551
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/24
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/-yV6wb3klSA
This commit introduces a new preference option
mathml.nonzero_unitless_lengths.disabled to disable MathML nonzero unitless
values like "5" for 500%. MathML nonzero unitless are now disabled by default
but it could be easily enabled again later if we decide otherwise.
* test_bug553917.html is updated to check that these values now cause an error
message to be logged into the console rather than a deprecated warning
when nonzero unitless lengths are disabled.
Additionally, the test checking invalid double dots "2..0" is updated not
to use unitless syntax.
* The old test 355548-3.xml checks support for mathsize names and also uses
several features that are going to be deprecated. So it is just run with
the proper preference adjustment.
* mfrac-linethickness-2.xhtml and number-size-1.xhtml check support for
unitless lengths so they are now run with that support enabled.
* WPT tests frac-linethickness-001.html and lengths-1.html are executed with
the some MathML features disabled in order to make them pass.
We get more assertion passing for the "Legacy numbers" test of
lengths-2.html ; however there are still some issues to address
(see bug 1574751).
Differential Revision: https://phabricator.services.mozilla.com/D42427
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/7
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/kyB34PjYXek
This commit introduces a new preference option
mathml.mathsize_names.disabled to disable mathsize keyword values. For
now, these are only disabled in Nightly builds.
* test_bug553917.html is updated to check that these values now cause an
error message to be logged into the console when mathsize names are used
and the feature disabled.
* The old test 355548-3.xml checks support for mathsize names and also uses
several features that are going to be deprecated. So it is just run with
the proper preference adjustment.
* mathml/relations/css-styling/mathsize-attribute-legacy-values.html passes
after this change so the test is run with the mathsize names disabled too
and the failure expectation is removed.
* mathml/relations/css-styling/mathsize-attribute-css-keywords.html is added
to check that CSS keywords won't be supported when we switch to using the
CSS parser in the future. This test passes now when the "small" keyword
is not accepted so it is run with the mathsize names disabled too.
Differential Revision: https://phabricator.services.mozilla.com/D42426
--HG--
extra : moz-landing-system : lando
This condition was needed when FindInsertionPrevSibling and co didn't understand
display: contents.
Editor is pretty broken (and calls into PresShell::ContentRemoved directly, and
incorrectly, using anonymous nodes).
In this case we were taking the XBL path because of display: contents, which
means that we tried to seek to the editor anonymous node, and crash (since it's
not an explicit kid).
Editor needs to get fixed, but this is technically more correct and fixes the
crash, so we may as well take it in the interim.
Differential Revision: https://phabricator.services.mozilla.com/D42472
--HG--
extra : moz-landing-system : lando
Update test_bug553917 so that it does not expect invalid lengths
for "thin", "thick", "medium" when mfrac linethickness names are
allowed. This fixes failure in non-nightly builds where these
names are not disabled yet.
Differential Revision: https://phabricator.services.mozilla.com/D42455
--HG--
extra : moz-landing-system : lando
When contents notify IME or requests something to IME, they need to use
an `nsIWidget` instance which may have focus if active, and handles
native keyboard/IME events since that knows correct native IME context.
Currently, such widget exactly matches with the result of
`nsPresContext::GetRootWidget()`. However, this is unclear for most developers.
Therefore, this patch creates a wrapper method of it named
`nsPresContext::GetTextInputHandlingWidget()`. Then, also adds
`BrowserParent::GetTextInputHandlingWidget()` wraps it. Finally, makes
`IMEStateManager` call `GetTextInputHandlingWidget()` of them.
Differential Revision: https://phabricator.services.mozilla.com/D42301
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/4
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/G91-vBeC3Rw
This commit introduces a new preference option
mathml.mfrac_linethickness_names.disabled to disable linethickness names. For
now, these names are only disabled in Nightly builds. Announcements and actual
disabling of this and other MathML features will be considered later.
* test_bug553917.html is updated to check that these values now cause an error
message to be logged into the console.
* mstyle-1.xhtml is updated to use a numeric linethickness since the point of
the test is just to check that the attribute is not supported on mstyle, not
about the actual attribute value.
* Other fractions tests relying on linethickness names are executed with the
proper preference adjustment.
* mathml/presentation-markup/fractions/frac-linethickness-001.html is now
closer to its expectation ; however the test still fails because nonzero
unitless values are not removed yet. See
https://github.com/mathml-refresh/mathml/issues/24
Differential Revision: https://phabricator.services.mozilla.com/D42323
--HG--
extra : moz-landing-system : lando
Resolution is at:
* https://github.com/w3c/csswg-drafts/issues/3779#issuecomment-481762912
Tests are at https://chromium-review.googlesource.com/c/chromium/src/+/1547974,
I'll make sure to wait until they're in the tree and ensure they're passing.
Note that we need to ensure in the frame constructor that the document element
is styled _before_ calling UpdateViewportScrollStylesOverride(). This saves
duplicated work (since ResolveStyleLazily throws away the style).
ResolveStyleLazily already returns out of date styles, unless the element is not
styled yet, or is in a `display: none` subtree, in which case it computes and
returns a new (up-to-date) style.
So the switch to the FFI call only should change behavior for the display: none
subtree case (since we ensure the unstyled case isn't hit by styling the
document earlier). But that case is one of the cases we're interested in
changing, conveniently.
Depends on D40080
Differential Revision: https://phabricator.services.mozilla.com/D39204
--HG--
extra : moz-landing-system : lando
Return a raw pointer instead of a strong reference to a ComputedStyle, and
handle the case of the style not being present by returning null rather than
requiring an extra function to check it and crashing if the precondition is not
met.
Also, name them so that it's clear they just return outdated styles and don't
make any extra effort.
This is just cleanup that makes the next patch easier / more obvious.
Differential Revision: https://phabricator.services.mozilla.com/D40080
--HG--
extra : moz-landing-system : lando
This is mostly straight-forward cleanup, but there's a behavior change which
was an oversight from bug 1386840, the regular mObservers stuff didn't pass the
right thing (was passing only mWasAlternate rather than whether it was
deferred).
I think that as a result, only in XML documents (since nsXMLContentSink is the
only thing that adds itself as a global CSS loader observer that ever looks at
this boolean), we may end up breaking this assert:
https://searchfox.org/mozilla-central/rev/9ae20497229225cb3fa729a787791f424ff8087b/dom/base/nsContentSink.cpp#183
(If there are any sheets with non-matching media queries and such).
But I couldn't find a test-case that broke it (tried SVG / XHTML), and in other
documents like pure XML you cannot specify a media query...
Differential Revision: https://phabricator.services.mozilla.com/D41091
--HG--
extra : moz-landing-system : lando
Saving a refcount bump is not worth the churn. Use a proper RefPtr<>
everywhere instead of manual refcounting, and don't make DoSheetComplete call
NS_RELEASE unconditionally.
Also, make clear by using references where null is expected or not.
Also, properly use a RefPtr in mPendingDatas, since they are strong pointers,
in fact.
Finally, remove some unused macros from nsCSSValue of which this code was the
last consumer.
Differential Revision: https://phabricator.services.mozilla.com/D41090
--HG--
extra : moz-landing-system : lando
They're bad, specially if they do vastly different thing in overloaded
functions, like aUseSystemPrincipal and aIsPreload. :)
Differential Revision: https://phabricator.services.mozilla.com/D40851
--HG--
extra : moz-landing-system : lando
Just moving code around but hopefully the new code is nicer :)
Also fix a regression I introduced in D40691 where the parsing mode wouldn't be
checked for XUL sheets.
Differential Revision: https://phabricator.services.mozilla.com/D40692
--HG--
extra : moz-landing-system : lando
The current code needs to handle incomplete draws already due to async decoding,
and this prevents the race condition where we paint between the size-available
and load notifications, as the CSS image loader only invalidates for the first.
Once we try to decode the image at least once, then we'd repaint properly from
ImageLoader::OnFrameComplete.
Differential Revision: https://phabricator.services.mozilla.com/D41006
--HG--
extra : moz-landing-system : lando
So the issue here is that this test-case has a zero-sized border, but still with
a border-image (which we should paint).
So the first time we get here, the image is not loaded, and thus we don't get
here:
https://searchfox.org/mozilla-central/rev/e0b0c38ee83f99d3cf868bad525ace4a395039f1/layout/painting/nsDisplayList.h#4254
Which means that we end up with zero bounds and thus we don't even get to the
border painting code.
However, when the image loads, we get to MarkNeedsDisplayItemRebuild(), but that
doesn't schedule any paint, only marks the frames as modified in order for
display items to be rebuilt _eventually_.
Thus eventually, where we force a repaint by other means, we paint correctly.
This only works in more general cases because we get to the nsImageRenderer code
which does vastly different stuff.
InvalidateFrame() seems to do the right thing and schedule a paint, so use it.
It's not clear to me which one of nsIFrame::InvalidateFrame() or
nsIFrame::SchedulePaint() we should use...
If I understand correctly, InvalidateFrame() will only do something iff there
are display items for the frame, so that should make the IsVisible() check
redundant.
Note however that I think there's still a race condition, if we get to paint in
between the SIZE_AVAILABLE notification (the one where we actually invalidate
the display items), and the LOAD notification (the one the border-image code
checks).
I'll send a separate patch for that, I think SIZE_AVAILABLE should be a
strong-enough hint and that allows us to remove nsStyleImage::IsLoaded()...
The RequestReflow stuff also looks highly suspicious... shape-outside
sync-decodes, and it seems we could end up invalidating reflow from the reflow
code...
Differential Revision: https://phabricator.services.mozilla.com/D41005
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/22
* mathml/relations/css-styling/attribute-mapping-001.html (length, dir)
* mathml/relations/html5-tree/display-1.html (display)
* mathml/relations/css-styling/displaystyle-1.html (displaystyle)
* mathml/relations/css-styling/displaystyle-2.html (displaystyle)
* mathml/relations/css-styling/mathvariant-case-sensitivity.html (mathvariant)
layout/reftests/bugs/355548-3.xml has been updated now that units are case
insensitive.
Note:
* mathml/relations/css-styling/attribute-mapping-002.html also checks
case insensitiveness of mathvariant and displaystyle but for now we map
these attributes to internal -moz-* CSS properties.
* mathcolor and mathbackground values are already case insensitive, this
is verified by mathml/relations/css-styling/attribute-mapping-001.html
Differential Revision: https://phabricator.services.mozilla.com/D42081
--HG--
extra : moz-landing-system : lando
This patch is auto-generated by the following command:
./mach clang-format -p layout/
Differential Revision: https://phabricator.services.mozilla.com/D42218
--HG--
extra : moz-landing-system : lando
Andrew Osmond
Mats Palmgren
Emilio Cobos Álvarez
Daniel Holbert
Frederic Wang
Andreea Pavel
Ciure Andrei
Jonathan Kew
Glenn Watson
Nicolas Silva
James Teh
Brad Werth
Gurzau Raul
Andrew Halberstadt
Sylvestre Ledru
Hiroyuki Ikezoe
Ting-Yu Lin
Florian Rivoal
shindli
Brian Grinstead
Adam Gashlin
Mihai Alexandru Michis
Michael Woerister
Boris Chiou
Luca Greco
Bob Owen
Cameron McCormack
Geoff Brown
Cosmin Sabou
Karl Tomlinson
Jared Wein
Nika Layzell
Gijs Kruitbosch
Tom Ritter
Kris Taeleman
Timothy Nikkel
Gerald Squelart
Xidorn Quan
Jonathan Watt
Noemi Erli
L. David Baron
Joel Olsson
Julian Descottes
Yura Zenevich
Andrew Creskey
Bogdan Tara
Miko Mynttinen
kriswright
Csoregi Natalia
Alex Vincent
Frédéric Wang
Botond Ballo
Randall E. Barker
Mike Hommey
Ryan VanderMeulen
Edgar Chen
Thomas Nguyen
Coroiu Cristina
Dan Glastonbury
singuliere
Masayuki Nakano
Charlie Marlow
Nicholas Nethercote