We still panic in a debug build, so that developers can notice when they
need to add a new static atom after modifying UA sheets.
We also add telemetry to note when this happens, add an app note to a
crash report, in case any crash later on occurs, and re-up the existing,
expired shared memory sheet telemetry probes so we can look at them
again.
Differential Revision: https://phabricator.services.mozilla.com/D73188
- Add IsWebRenderEnabled() method to property_database.js
- Check for WebRender in addition to backdrop-filter pref
- Update relevant WPT cases to expect fail if not webrender
Differential Revision: https://phabricator.services.mozilla.com/D74162
- Enable BackdropFilter pref by default
- Add function IsBackdropFilterAavailable()
- Use IsBackdropFilterAvailable for relevant WebIDL instead of pref
- Add test for BackdropFilter availability
Differential Revision: https://phabricator.services.mozilla.com/D73967
- Add IsWebRenderEnabled() method to property_database.js
- Check for WebRender in addition to backdrop-filter pref
- Update relevant WPT cases to expect fail if not webrender
Differential Revision: https://phabricator.services.mozilla.com/D74162
- Enable BackdropFilter pref by default
- Add function IsBackdropFilterAavailable()
- Use IsBackdropFilterAvailable for relevant WebIDL instead of pref
- Add test for BackdropFilter availability
Differential Revision: https://phabricator.services.mozilla.com/D73967
The motivation here is that we will want to call CSSTransition specific
functions, e.g. updating the start value of a given CSSTransition with
the latest value of the CSSTransition on the compositor, from somewhere
not in layout/style. Unfotunately nsTransitionManager.h is not exposed
and we will never want to expose it since it's purely for layout/style
stuff.
Depends on D73570
Differential Revision: https://phabricator.services.mozilla.com/D73571
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
The motivation here is that we will want to call CSSTransition specific
functions, e.g. updating the start value of a given CSSTransition with
the latest value of the CSSTransition on the compositor, from somewhere
not in layout/style. Unfotunately nsTransitionManager.h is not exposed
and we will never want to expose it since it's purely for layout/style
stuff.
Differential Revision: https://phabricator.services.mozilla.com/D73571
Since mTransitionProperty keep holding the original transition property even if
the target effect or keyframe was replaced by others. We need to make sure the
current transition is runnable on the compositor, i.e. having the effect and
keyframes and one of the properties is runnable on the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D73586
- Add new function `nsCSSProps::RecomputeEnabledState()`
- Register callbacks to `RecomputeEnabledState` instead of using `BoolVarCache`
Differential Revision: https://phabricator.services.mozilla.com/D73356
- Add new data member StyleSheet::mParentObject
- Clone Sheets before adding them to nsXULPrototypeCache
- Return mParentObject from GetParentObject if non-null
Differential Revision: https://phabricator.services.mozilla.com/D72725
i.e. remove annotations that manually enable the property, and remove the
property_database.js check that tests for the property being enabled.
We've been shipping with the property enabled ever since Firefox 69, so we're
realistically not going to default-disable it at this point, which means these
annotations (and the property_database.js check) are just cruft.
Differential Revision: https://phabricator.services.mozilla.com/D69128
Should also have no behavior change.
After the previous patch we don't have sheets associated with a document but
not owned by it, so take advantage of that.
Differential Revision: https://phabricator.services.mozilla.com/D71264
This removes StyleSheet::GetComposedDoc because it wasn't doing the
right thing, and while constructable stylesheets _could_ in theory
return something meaningful (the constructor doc iff any adopters is
connected), it's not a concept we need in other places for now.
Differential Revision: https://phabricator.services.mozilla.com/D71261
- Add new CSS Error
- Add new test case for error
- Ensure that test cases use `replace()` and `replaceSync()`
Differential Revision: https://phabricator.services.mozilla.com/D69423
--HG--
extra : moz-landing-system : lando
This includes:
- Removal of `px` after a `0`
- Combining of logical properties
- Removal of spaces between "!" and "important"
Differential Revision: https://phabricator.services.mozilla.com/D69861
--HG--
extra : moz-landing-system : lando
P2 removed IsTimerPrecisionReductionEnabled and thus removed the check for RFP
pref. While most ReduceTimePrecision* functions are fine with that because
GetTimerPrecisionType checks that, the two ReduceTimePrecision*RFP functions
miss the check.
This patch mainly cover the check for that two functions and rename them to
*RFPOnly since they only use RFP when the pref is on.
Depends on D64324
Differential Revision: https://phabricator.services.mozilla.com/D66734
--HG--
extra : moz-landing-system : lando
To support checking CrossOriginIsolated in performance.now(), we need to:
- Add new types to TimerPrecisionType for nsRFPService
- System, HighResAllowed are added
- All is renamed to Normal
- Introduce a set of Reduce methods which require isSystemPrincipal and
CrossOriginIsolated to be passed and decide the TimerPrecisionType later
- Original Reduce methods should only be called when callsites know the
TimerPrecisionType. Otherwise, they should call the new methods.
- The following patches will use new methods
Differential Revision: https://phabricator.services.mozilla.com/D63293
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--HG--
extra : moz-landing-system : lando
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
According to spec, option elements with label attributes should show and use
those labels rather than their element text. So let's do that.
Requires some trickery because the option element is a block element (so it
lays out its width based on its text content) so we put its label (if it has
one) in its ::before and skip frame generation so it measures the text of its
label, not of its text node children.
Differential Revision: https://phabricator.services.mozilla.com/D63545
--HG--
extra : moz-landing-system : lando
We confirmed that this is a networking issue, no point in making beta /
devedition crash due to this. Still worth keeping it on nightly to monitor the
crash volume once the networking fix arrives.
Differential Revision: https://phabricator.services.mozilla.com/D69602
--HG--
extra : moz-landing-system : lando
This is a bit hacky, but is how it used tow work without the native theme. We
may be able to do better.
<input type="date"> / <input type="time"> work the same way with and without the
other two selectors, because they never match since we moved them to shadow DOM
in Firefox 65 (bug 1496242).
Differential Revision: https://phabricator.services.mozilla.com/D69552
--HG--
extra : moz-landing-system : lando
According to spec, option elements with label attributes should show and use
those labels rather than their element text. So let's do that.
Requires some trickery because the option element is a block element (so it
lays out its width based on its text content) so we put its label (if it has
one) in its ::before and skip frame generation so it measures the text of its
label, not of its text node children.
Differential Revision: https://phabricator.services.mozilla.com/D63545
--HG--
extra : moz-landing-system : lando
Turns out that align-self is enough for sizing to end up like we want (not
getting squashed by the flex container's padding). This prevents double-applying
the padding in cases where the top and bottom paddings don't match.
We also fix another change from my previous patch, which is that we wouldn't
clip stuff if the text editor is much bigger than the flex container. Most
trivial example of this is:
data:text/html,<input type=number style="font-size: 300px; height: 40px;">
I renamed the test from overflow-clip-box-* to padding-*, as we're not
technically exercising overflow-clip-box anymore, and added a test for the
clipping too.
Differential Revision: https://phabricator.services.mozilla.com/D68535
--HG--
rename : layout/reftests/forms/input/number/overflow-clip-box-notref.html => layout/reftests/forms/input/number/padding-001-notref.html
rename : layout/reftests/forms/input/number/overflow-clip-box-ref.html => layout/reftests/forms/input/number/padding-001-ref.html
rename : layout/reftests/forms/input/number/overflow-clip-box.html => layout/reftests/forms/input/number/padding-001.html
rename : layout/reftests/forms/input/number/overflow-clip-box-ref.html => layout/reftests/forms/input/number/padding-002-ref.html
rename : layout/reftests/forms/input/number/overflow-clip-box.html => layout/reftests/forms/input/number/padding-002.html
extra : moz-landing-system : lando
Turns out that align-self is enough for sizing to end up like we want (not
getting squashed by the flex container's padding). This prevents double-applying
the padding in cases where the top and bottom paddings don't match.
We also fix another change from my previous patch, which is that we wouldn't
clip stuff if the text editor is much bigger than the flex container. Most
trivial example of this is:
data:text/html,<input type=number style="font-size: 300px; height: 40px;">
I renamed the test from overflow-clip-box-* to padding-*, as we're not
technically exercising overflow-clip-box anymore, and added a test for the
clipping too.
Differential Revision: https://phabricator.services.mozilla.com/D68535
--HG--
rename : layout/reftests/forms/input/number/overflow-clip-box.html => layout/reftests/forms/input/number/padding-notref.html
rename : layout/reftests/forms/input/number/overflow-clip-box-ref.html => layout/reftests/forms/input/number/padding-ref.html
rename : layout/reftests/forms/input/number/overflow-clip-box-notref.html => layout/reftests/forms/input/number/padding.html
extra : moz-landing-system : lando
AudioWorklets are now functional for most use cases, and so it's time to allow
people to experiment.
PaintWorklets are not ready.
Differential Revision: https://phabricator.services.mozilla.com/D68320
--HG--
extra : moz-landing-system : lando
This patch computes the author-specified properties during the CSS cascade, and
removes the complex rule-tree-based implementation that tries to do the cascade
again.
This changes behavior in two ways, one of them which is not observable to
content, I believe:
* revert now re-enables the native styling. This was brought up in
https://github.com/w3c/csswg-drafts/issues/4777 and I think it is a bug-fix.
This is observable to content, and I'm adding a test for it.
* We don't look at inherited styles from our ancestors when `inherit` is
specified in a non-author stylesheet. This was introduced for bug 452969 but
we don't seem to inherit background anymore for file controls or such. It
seems back then file controls used to have a text-field.
I audited forms.css and ua.css and we don't explicitly inherit
padding / border / background-color into any nested form control.
We keep the distinction between border/background and padding, because the later
has some callers. I think we should try to align with Chromium in the long run
and remove the padding bit.
We need to give an appearance to the range-thumb and such so that we can assert
that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new
internal value for that.
Differential Revision: https://phabricator.services.mozilla.com/D67722
--HG--
extra : moz-landing-system : lando
This patch computes the author-specified properties during the CSS cascade, and
removes the complex rule-tree-based implementation that tries to do the cascade
again.
This changes behavior in two ways, one of them which is not observable to
content, I believe:
* revert now re-enables the native styling. This was brought up in
https://github.com/w3c/csswg-drafts/issues/4777 and I think it is a bug-fix.
This is observable to content, and I'm adding a test for it.
* We don't look at inherited styles from our ancestors when `inherit` is
specified in a non-author stylesheet. This was introduced for bug 452969 but
we don't seem to inherit background anymore for file controls or such. It
seems back then file controls used to have a text-field.
I audited forms.css and ua.css and we don't explicitly inherit
padding / border / background-color into any nested form control.
We keep the distinction between border/background and padding, because the later
has some callers. I think we should try to align with Chromium in the long run
and remove the padding bit.
We need to give an appearance to the range-thumb and such so that we can assert
that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new
internal value for that.
Differential Revision: https://phabricator.services.mozilla.com/D67722
--HG--
extra : moz-landing-system : lando
- Add functionality to clone adopted style sheets for printing.
- Add reftest to ensure that the document's adopted styles show in print.
- Add reftest to ensure that a shadow root's adopted styles show in print.
Differential Revision: https://phabricator.services.mozilla.com/D66517
--HG--
extra : moz-landing-system : lando
To correctly implement this, it must be known on instantiation whether E is
copy-constructible, which is not the case if only a forward declaration is
available. This can be resolved either by making sure a full definition of E is
available, which is preferable. But in cases where this is not (easily) possible,
the information can be explicitly provided by the MOZ_DECLARE_COPY_CONSTRUCTIBLE
and MOZ_DECLARE_NON_COPY_CONSTRUCTIBLE macros. In particular, declarations for
IPDL-declared types are added to nsTArray.h itself, like it was already done
for MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR.
Differential Revision: https://phabricator.services.mozilla.com/D66244
--HG--
extra : moz-landing-system : lando
Specifically, this renames
* nsTArray_CopyChooser to nsTArray_RelocationStrategy
* the Copy template argument of nsTArray_base to RelocationStrategy
* nsTArray_CopyWithConstructors to nsTArray_RelocateUsingMoveConstructor
* nsTArray_CopyWithMemutils to nsTArray_RelocateUsingMemutils
* DECLARE_USE_COPY_CONSTRUCTORS to MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR
Differential Revision: https://phabricator.services.mozilla.com/D66243
--HG--
extra : moz-landing-system : lando
This never worked, but it's more visible with the new form controls which have
more padding.
Make the anonymous div and co a pseudo-element, so that they inherit from the
<input> properly in all cases. This works for non-number inputs because the
editor root is a direct child of the <input>, but it doesn't for number inputs
because there's a flex wrapper in between.
This way overflow-clip-box: inherit does what we want. Reset the padding in the
inline direction, as the padding for <input type=number> applies to the arrow
boxes as well, and thus we'd double-apply it.
Differential Revision: https://phabricator.services.mozilla.com/D65271
--HG--
extra : moz-landing-system : lando
Expect forced-colors-mode-backplate tests to fail because they were passing for the wrong reason,
and the backplate is now properly applied, causing them to fail.
Remove tests for field and fieldtext from color-valid.html because they are tested again
in system-color-valid.html.
Differential Revision: https://phabricator.services.mozilla.com/D66879
--HG--
extra : moz-landing-system : lando
Expect forced-colors-mode-backplate tests to fail because they were passing for the wrong reason,
and the backplate is now properly applied, causing them to fail.
Remove tests for field and fieldtext from color-valid.html because they are tested again
in system-color-valid.html.
Differential Revision: https://phabricator.services.mozilla.com/D66879
--HG--
extra : moz-landing-system : lando
