It improves rasterization and upload times by a lot in almost all of the test cases I can find. The only drawback is that our invalidation granulatiry is the tile so invalidation gets coarser as we increase the tile size.
512 is a bit special because it is the limit above which a different texture upload path is taken, so there will be more risk of performance side effects if/when we decide to make tiles even larger.
Differential Revision: https://phabricator.services.mozilla.com/D155822
In nightly and early beta, we still use 0.5 as the threshold so we can collect more data.
In release, use 0.95 as the threshold
Differential Revision: https://phabricator.services.mozilla.com/D155486
- remove flag and corresponding warning/counter.
- remove attribute from parsers, but keep the atom since it's
used by TreeSanitizer.
- remove tests for mfrac@bevelled, there is a WPT test to check it's
not supported.
- layout/mathml/tests/test_bug975681.html is removed, its tests are
currently (wrongly) all disabled when the flag is off and equivalent
tests for attributes other than bevelled exist in WPT.
Differential Revision: https://phabricator.services.mozilla.com/D154199
- Remove preference, warning and counter.
- Remove tests checking support for it, or replacing with
equivalent 50% and 300% values.
Differential Revision: https://phabricator.services.mozilla.com/D154198
- Remove code for align/denumalign/numalign attributes.
- Remove tests checking support for them.
- Remove warning message and counter.
- numalign/denomalign atoms are not removed, since they
are still used by nsTreeSanitizer.
Differential Revision: https://phabricator.services.mozilla.com/D154197
- Remove script_shift_attributes preference and related test, warning
message and parsing.
- Do not remove subscriptshift/supscripshift atoms, since they are
still needed for nsTreeSanitizer.
Differential Revision: https://phabricator.services.mozilla.com/D154195
There are a couple of current issues/discussions that may lead to a change in the set of supported keywords, so we may want to hold back a little on actually shipping this.
- In https://github.com/w3c/IFT/pull/113, the WebFonts WG proposes several new incremental-* keywords (and maybe implies dropping the currently-defined incremental?)
- In https://github.com/w3c/csswg-drafts/issues/7633, I just proposed renaming the feature-* keywords to features-* (plural) for better readability; I'd like to see a decision on that before we ship this to release.
Differential Revision: https://phabricator.services.mozilla.com/D155458
It turns out that websites break with different reasons when hiding things. At this point we want to stop revising the hack further and instead gather the data about how many websites are currently affected.
Differential Revision: https://phabricator.services.mozilla.com/D154578
The patch implements a CookieBanner JSWindowActor. The CookieBanner
actor will be created when the DOMContentLoaded event files, and try to
detect the cookie banner and click the button to handle it.
Differential Revision: https://phabricator.services.mozilla.com/D154806
There are compat issues with the approach. There are future plans to restore the functionality but only when typing into a text area.
Differential Revision: https://phabricator.services.mozilla.com/D155275
The patch implements a CookieBanner JSWindowActor. The CookieBanner
actor will be created when the DOMContentLoaded event files, and try to
detect the cookie banner and click the button to handle it.
Differential Revision: https://phabricator.services.mozilla.com/D154806
It turns out that websites break with different reasons when hiding things. At this point we want to stop revising the hack further and instead gather the data about how many websites are currently affected.
Differential Revision: https://phabricator.services.mozilla.com/D154578
This also introduce a pref which protect these two attributes:
dom.picture_source_dimension_attributes.enabled.
These two dimension attributes will be mapped to the style of <img> elements
if the <source> element's parent is <picture>. This will be implemented
in the later patch. For now, we just implement the DOM interface.
Differential Revision: https://phabricator.services.mozilla.com/D152585
It turns out that websites break with different reasons when hiding things. At this point we want to stop revising the hack further and instead gather the data about how many websites are currently affected.
Differential Revision: https://phabricator.services.mozilla.com/D154578
The ColorSchemeMode::Preferred change doesn't make a difference (that
is, always use the preferred one), since when we only propagate from
top's embedder the embedder is chrome, which always has the preferred
color-scheme.
Differential Revision: https://phabricator.services.mozilla.com/D154931
Backdrop filter crashes newer Intel drivers on Windows. This patch adds
support to the blocklist infrastructure for backdrop filter, and hooks
this up with the CSS property table.
Differential Revision: https://phabricator.services.mozilla.com/D154950
Fix some tests to:
* Not assume `double` precision.
* Account for recent working group resolution with regards to NaN: https://github.com/w3c/csswg-drafts/issues/7067#issuecomment-1111211295
Not sure I caught all, but normalizing to 0 was already our existing
behavior. This feature needs more work before it can be enabled more
generally, so make it nightly-only, for now.
Also, it's unclear per spec what the serialization for infinity*1s or so
should be. Right now we serialize to <very-big-number>s, which seems
reasonable, but some tests (but not others!) expect different behavior.
I left those untouched for now.
Differential Revision: https://phabricator.services.mozilla.com/D154883
We now have test coverage, so let's do this.
The remaining failures are just about infinity/nan, which is a
completely different feature.
Differential Revision: https://phabricator.services.mozilla.com/D154831
Backdrop filter crashes newer Intel drivers on Windows. This patch adds
support to the blocklist infrastructure for backdrop filter, and hooks
this up with the CSS property table.
Differential Revision: https://phabricator.services.mozilla.com/D154950
It seems that making animation shorthand supports animation-composition may be
very tricky, so it's unlikely to include animation-composition into the
shorthand for now, per spec issue:
https://github.com/w3c/csswg-drafts/issues/6946.
WebKit also supports the longhand only on STP (Safari Technology Preview), so
it should be fine to enable the longhand property only on Firefox Nightly,
for experiemental testing.
Differential Revision: https://phabricator.services.mozilla.com/D154934
Fix some tests to:
* Not assume `double` precision.
* Account for recent working group resolution with regards to NaN: https://github.com/w3c/csswg-drafts/issues/7067#issuecomment-1111211295
Not sure I caught all, but normalizing to 0 was already our existing
behavior. This feature needs more work before it can be enabled more
generally, so make it nightly-only, for now.
Also, it's unclear per spec what the serialization for infinity*1s or so
should be. Right now we serialize to <very-big-number>s, which seems
reasonable, but some tests (but not others!) expect different behavior.
I left those untouched for now.
Differential Revision: https://phabricator.services.mozilla.com/D154883
We now have test coverage, so let's do this.
The remaining failures are just about infinity/nan, which is a
completely different feature.
Differential Revision: https://phabricator.services.mozilla.com/D154831
By making image loading in <embed> and <object> behave more like when
an <iframe> loads an image, we can make sure that the synthetic
document generated is process switched if the image is cross
origin. This is done by making image loading in nsObjectLoadingContent
follow the document loading path.
We also make sure that we pass the image size back to the embedder
element to not get stuck with the intrinsic size.
To avoid named targeting being able to target these synthetic
documents, as well as showing up in `Window.frames` and being counted
in `Window.length`, we keep a filtered list of non-synthetic browsing
contexts for that use-case.
This feature is controlled by two prefs:
* browser.opaqueResponseBlocking.syntheticBrowsingContext
This triggers the creation of synthetic documents for images loaded
in <object> or embed.
* browser.opaqueResponseBlocking.syntheticBrowsingContext.filter
This turns on the filtering of synthetic browsing contexts in named
targeting, `Window.length` and `Window.frames`.
Differential Revision: https://phabricator.services.mozilla.com/D148117