Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
It's very hot when matching some kind of selectors like the ones in bug
1717267, and the two function calls show up in the profiles.
Differential Revision: https://phabricator.services.mozilla.com/D119505
Some pages use this to hide the focus outline. On Blink it seems black,
WebKit uses it to expose the OS accent color. Make it black, which is
the default when the color isn't implemented on a given platform.
Differential Revision: https://phabricator.services.mozilla.com/D119036
nsIDOMWindowUtils.getOMTAStyle is for querying an in-progress animating value
running on the compositor thread. The key to query the value is stored in the
target nsIFrame of the animating element, and the key is basically based on
the display item (type) in question, DisplayItemType::TYPE_TRANSFORM in cases of
transform animations, etc. So if getOMTAStyle gets called for an element
where
a) an animation is running on the compositor
b) a new animation is just created
then, it's possible that getOMTAStyle queries a)'s animation value instead of
b)'s.
Differential Revision: https://phabricator.services.mozilla.com/D119127
No functional change, this just makes it more explicit that each possible status
value is being considered, and unifies the handling of the two arrays.
Differential Revision: https://phabricator.services.mozilla.com/D118200
This changes font-family storage to reuse the rust types, removing a
bunch of code while at it. This allows us to, for example, use a single
static font family for -moz-bullet and clone it, rather than creating a
lot of expensive copies.
Differential Revision: https://phabricator.services.mozilla.com/D118011
Just drive-by, but seems reasonable to avoid the per-element comparison
if the pointers are the same.
Depends on D118015
Differential Revision: https://phabricator.services.mozilla.com/D118016
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
Per https://github.com/w3c/csswg-drafts/issues/6126 these were
never intended to be included in the first place so this is just
fixing a bug. Note that I'm leaving them in the mRuleFaces array
so that the font loading machinery works the same as before.
I'm just excluding them when queried by document.fonts.
Differential Revision: https://phabricator.services.mozilla.com/D111694
Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
Per https://github.com/w3c/csswg-drafts/issues/6126 these were
never intended to be included in the first place so this is just
fixing a bug. Note that I'm leaving them in the mRuleFaces array
so that the font loading machinery works the same as before.
I'm just excluding them when queried by document.fonts.
Differential Revision: https://phabricator.services.mozilla.com/D111694
Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
This results in lots of new WPT test passes.
There were also a couple of WPT tests that turned out to be broken;
tab-size-inline-001 and -002 had errors in their reference files such
that they'd never pass anywhere. So those are fixed here.
Depends on D117331
Differential Revision: https://phabricator.services.mozilla.com/D117332
So we update d property in the style system as well. This makes sure we
have the correct computed style and the correct rendering result.
Differential Revision: https://phabricator.services.mozilla.com/D115570
Support fit-content for preferred size, min size, and max size. This
patch only implement the style system. For layout part, we will do that
in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D107161
In this particular case the issue wouldn't end up in any sort of memory
corruption if we didn't safely crash, but these are quite tricky to
reason about, so it's better to avoid the reentrancy altogether if
possible.
I tried to convert the fuzzer test-case in a crashtest but failed (as
in, it didn't crash without the patch under the test harness).
Differential Revision: https://phabricator.services.mozilla.com/D115943
In this particular case the issue wouldn't end up in any sort of memory
corruption if we didn't safely crash, but these are quite tricky to
reason about, so it's better to avoid the reentrancy altogether if
possible.
I tried to convert the fuzzer test-case in a crashtest but failed (as
in, it didn't crash without the patch under the test harness).
Differential Revision: https://phabricator.services.mozilla.com/D115943
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
As per https://drafts.csswg.org/css-will-change/#will-change.
> If any non-initial value of a property would cause the element to
> generate a containing block for absolutely positioned elements,
> specifying that property in will-change must cause the element to
> generate a containing block for absolutely positioned elements.
But in this case the transform property wouldn't apply to the element so
there's no reason to create a stacking-context.
Differential Revision: https://phabricator.services.mozilla.com/D114121
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
It's the wrong pseudo-class name! Plus, it's not really needed, just
override the page styles temporarily.
Remove the pseudo-class, since it's its only remaining usage.
Differential Revision: https://phabricator.services.mozilla.com/D113374
This will allow detecting the system theme, which allows fixing some of
the blocked bugs.
Note that when using the system theme we will still match light or dark
appropriately, so this shouldn't change behavior just yet.
Differential Revision: https://phabricator.services.mozilla.com/D113516
https://drafts.csswg.org/css-images-4/#image-set-notation has:
> [...] it also specifies the image’s natural resolution, overriding any other
> source of data that might supply a natural resolution.
Astounding that there was literally no WPT for this at all. I added three: one
for backgrounds, one for list-style-image, and one for `content`. Cursor is not
handled on this patch because that one requires a fair amount of extra work.
Differential Revision: https://phabricator.services.mozilla.com/D112474
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
I need to use these from Rust to insert mapped attribute names in the
bloom filter, and this would save me handrolling even more bindings :)
Differential Revision: https://phabricator.services.mozilla.com/D111731
No behavior change, just cleanup. Actually seem this technically _adds_ some code even
though it's a cleanup, but that's mostly because of the wrapping of the
derive list. The resulting code is simpler (more in-line with our usual
things, so I think it's an improvement).
Differential Revision: https://phabricator.services.mozilla.com/D111551
This is a preliminary step that is needed in order for the following patch to be safe. (It's
mostly just plumbing, although the patch looks big because we need to pass the index through
so many functions.)
The issue is that loading a font resource involves a couple of tasks that happen asynchronously -
fetching the data from the network, and decoding/sanitizing the font data. We have an implicit
assumption that once a font load has been initiated, the state of the associated gfxUserFontEntry
will not change; in particular, we depend on mSrcIndex remaining constant, because we may use it
to index into the mSrcList array and access the gfxFontFaceSrc record again in the various
completion tasks that are executed after the async steps finish.
But the following patch breaks this assumption, because it may reset mSrcIndex at arbitrary times
when we discover that we need to re-resolve the @font-face to potentially recognize a src:local()
resource that was earlier in the list, but was previously unavailable. If this happens while
a font-load is doing its off-main-thread work, then when it completes, it will end up accessing
the wrong gfxFontFaceSrc record, which would result at least in incorrect behavior, but can also
result in a crash (e.g. if the record is of the wrong type altogether, such as trying to use the
principal or URI fields from a record of type src:local).
To avoid this problem, we should pass the source index at the time the font load is initiated
through to the OMT tasks and back to their main-thread completion routines, so that we do not
depend on the field in the gfxUserFontEntry remaining frozen. This makes the loading process
safe even if the source index in the entry gets reset while loading tasks are in progress.
Differential Revision: https://phabricator.services.mozilla.com/D110911
There's no reason we can't just query LookAndFeel and we need to use
sSystemMetrics. In the past, LookAndFeel queries were not cached, but
this is no longer the case, so perf wise should be pretty equivalent.
Note that we don't need the NS_SUCCEEDED checks because the default
value from GetInt if the platform doesn't support it is 0 anyways.
Differential Revision: https://phabricator.services.mozilla.com/D110805
This matches Chrome and Safari, as well as what we do for all other <input>s.
<input>s were changed to inline block in 1539469 with a couple of font inflation reftests marked as failing to follow up on. https://hg.mozilla.org/mozilla-central/rev/a1201db1b8cc is the follow up which made inputs not be font inflation containers. The same change for textarea fixes similar reftest failures for textarea. I read through the commit message for the change and doing the same for textareas seems to make sense but I don't understand it in detail.
Differential Revision: https://phabricator.services.mozilla.com/D109603
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This makes us match Blink and WebKit on how to render an iframe whose src
attribute is an image URL. They seem to have always used 0 margin in this
case, and this seems preferable from an author's perspective (since the
standard HTML-body margin feels kind of arbitrary, when viewing an image).
Note that this change does also mean that images will be slightly closer to the
upper-left of the page, if they're viewed directly and then printed. This
shouldn't cause them to be clipped or cause other issues; they'll still be
offset from the page edge by the printed-page margins, as well as any
unprintable areas that we get from the printer.
Differential Revision: https://phabricator.services.mozilla.com/D110294
Sonia Singla
Butkovits Atila
Agi Sferro
Iulian Moraru
Sandor Molnar
Florian Quèze
Emilio Cobos Álvarez
Adam Bruce
Dorel Luca
Alexandru Michis
Hiroyuki Ikezoe
Narcis Beleuzu
Paul Zuehlcke
Jonathan Kew
Niklas Goegge
Matt Woodrow
Michelle Goossens
Boris Chiou
Mats Palmgren
Marian-Vasile Laza
Andrew Halberstadt
Ting-Yu Lin
Nazım Can Altınova
Xidorn Quan
Csoregi Natalia
Noemi Erli
Kris Wright
Andi-Bogdan Postelnicu
Emma Malysz
Joel Maher
Mark Striemer
Tom Schuster
Pierre TALLOTTE
Morgan Reschenberg
Marco Bonardo
Cosmin Sabou
Hubert Boma Manilla
Timothy Nikkel
Daniel Holbert
Neil Deakin
Darryl Pogue