-moz-inert CSS property reflects inert subtrees concept and can be used to implement HTML:dialog element and HTML:inert attribute
Differential Revision: https://phabricator.services.mozilla.com/D81701
As per the following change to the spec:
6b3d7240b5
The additional failure annotation is added because we don't currently treat
text-combine-upright as non-animatable and this patch exposes the existing bug
(bug 1654195).
Differential Revision: https://phabricator.services.mozilla.com/D84308
This fixes performance issues when there's a massive number of rules and
a massive DOM.
Instead of going through all rules for all the DOM, we now look stuff in
hashmaps.
Differential Revision: https://phabricator.services.mozilla.com/D83506
Instead add a pseudo-class that does the expected size="" attribute parsing.
Removing the Gtk-specific rule setting the text color since it doesn't
seem to have any effect currently.
Differential Revision: https://phabricator.services.mozilla.com/D83448
Forgot to follow up on these two remaining non-standard values that may have
been being used to reset a <meter> or <input type=number> back to its
original appearance, but which telemetry showed no usage of.
Differential Revision: https://phabricator.services.mozilla.com/D83598
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
This hooks the "monochrome" media query and co to the
nsIPrintSettings.printInColor setting.
This print setting we're using is not exposed in the print preview UI,
but you can test it setting the print.print_in_color preference to
"false", and then print preview will correctly show up greyscale'd.
Once this lands, the UI folks just have to use it as they see fit :)
I would've liked to add a proper rendering test, but the print reftests
check only whether the PDF text matches.
I could add a test to printpreview_helper.xhtml, but I'm refactoring
that file in bug 1648064 so I'd rather wait a bit and add it in a
separate bug. The test for the media feature should make sure that we
test that code path at least.
Differential Revision: https://phabricator.services.mozilla.com/D83552
By the time we get to iterate over the longhands of a shorthand, we've
already advanced the range iterator, so we look at the next duration and
such, which causes this bug.
I'm seriously baffled that no existing test caught this when it
landed, neither in our internal test suite nor wpt... :/
Differential Revision: https://phabricator.services.mozilla.com/D82396
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
This does not (yet) upgrade ./rust-toolchain
The warnings:
* dead_code "field is never read"
* redundant_semicolons "unnecessary trailing semicolon"
* non_fmt_panic "panic message is not a string literal, this is no longer accepted in Rust 2021"
* unstable_name_collisions "a method with this name may be added to the standard library in the future"
* legacy_derive_helpers "derive helper attribute is used before it is introduced" https://github.com/rust-lang/rust/issues/79202
The process of decoding the network byte stream to Unicode is backed by
an instance of `encoding_rs::Decoder`, which will switch the encoding it
uses if it finds a BOM in the byte stream. However, this change in
encoding is not communicated back to the caller and so
`document.characterSet` gives the wrong result. This change fixes that.
See whatwg/html#5359 and whatwg/encoding#203 for the spec-level backing
for this change.
Signed-off-by: Andreu Botella <abb@randomunok.com>
