This is based off work by smurfd. But this patch doesn't support buttons
both at the left and right, which simplifies a lot the implementation.
Also, clean-up the existing env variables while at it.
Co-authored-by: Nicklas Boman <smurfd@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D132073
Since spatial node indices are now stable across display lists,
we can include them in the interned data for clips.
This means that much of the code complexity related to clip
instances can be removed (though this is left for a follow
up patch once this has been in nightly for some time without
causing any regressions).
Long term, this means that clips are retained between display lists
along with their positioning information. We can take advantage of
this to cache state / dependencies about clips between different
display lists, which will eliminate some redundant clip work we
currently do every scene/frame build.
Differential Revision: https://phabricator.services.mozilla.com/D131962
Applying it to SVG-transformed frames is wrong, and causes us to
rasterize rather massive SVGs. This is consistent with the other CSS
3d transforms code, and our rendering of the test-case matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D132040
We have other code to make sure that options themselves are in-flow, so
we really want abspos boxes not to escape the select element.
Other browsers don't allow having out-of-flow option children at all
(they seem to force descendants to be in-flow). However that seems
fairly more complicated to implement, and I don't think it particularly
matters how we deal with this as long as we deal with it in a
sorta-reasonable way.
Differential Revision: https://phabricator.services.mozilla.com/D131785
We have other code to make sure that options themselves are in-flow, so
we really want abspos boxes not to escape the select element.
Other browsers don't allow having out-of-flow option children at all
(they seem to force descendants to be in-flow). However that seems
fairly more complicated to implement, and I don't think it particularly
matters how we deal with this as long as we deal with it in a
sorta-reasonable way.
Differential Revision: https://phabricator.services.mozilla.com/D131785
This was a subtle behavior change in bug 1739464. The early-return here:
https://hg.mozilla.org/mozilla-central/rev/2fb74c67b0c5#l11.40
Meant we also bailed out from user font prioritization for system fonts.
It's unclear whether that's really the best behavior but since the
intention of the regressing patch was not to change behavior, preserving
the old behavior seems better.
Differential Revision: https://phabricator.services.mozilla.com/D131899
Given the compat reports in bug 1484928, I don't think it's worth
keeping the current behavior.
Our behavior should match other browsers now. Rather than making
content: url() work everywhere even for otherwise-replaced elements,
just special-case this since that's what other browsers seem to do.
Differential Revision: https://phabricator.services.mozilla.com/D131797
.fallback is always the default font for the lang group unless we're a
system font (in which case it's "none").
The only reason we need that is because we need to react to
language changes (which affect the initial font).
Simplify the model a bit doing the language lookup in gfxTextRun (this
should avoid allocating a few nsStyleFont structs too.
Depends on D130732
Differential Revision: https://phabricator.services.mozilla.com/D131312
This seems like more sensible behavior. We have another use of
only_generic(), but that affects font sizing and other browsers agree
with us there:
<div style="font-family: monospace">Should be 13px</div>
<div style="font-family: something, monospace">Should be 16px</div>
So not touching that one.
Differential Revision: https://phabricator.services.mozilla.com/D130732
Apparently using transparent borders and outlines is a common
accessibility technique to make those visible in HCM.
Bug 1740924 comment 9 seemed to indicate we were the only browser
rendering those browsers, but I just confirmed that Edge at least does
show them.
Keep respecting system colors as that's per spec.
Differential Revision: https://phabricator.services.mozilla.com/D131412
The way CommitStyles called into servo caused it to call the closure
multiple times, and we were not dealing with that properly.
Handle the "was called" state internally.
Differential Revision: https://phabricator.services.mozilla.com/D131411
It might fire before styles are invalidated, so it might cache the wrong
styles.
Instead, fire an event on the window once everything in that window has
been invalidated, not just the global theme.
This is causing failures with the patch in bug 1740089, since after that
patch `browser_ext_browserAction_theme_icons` trigger the theme changes
when switching from dark to default mode or similar.
Differential Revision: https://phabricator.services.mozilla.com/D131396
Annotating each test individually lets us avoid introducing new failing tests
while we go through the backlog of failing tests.
Depends on D129162
Differential Revision: https://phabricator.services.mozilla.com/D129163
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
As per spec. This could cause wrong styles to be returned because we
fill the bloom filter based on flat tree ancestors, which was ultimately
the root cause of bug 1737131.
Differential Revision: https://phabricator.services.mozilla.com/D131074
We only need to clean up the frames for its flat tree children which are
about to go away from the flat tree, but we don't need to do anything
else. This avoids issues with the following patches because menupopups
depend a lot on their frame tree state.
Differential Revision: https://phabricator.services.mozilla.com/D131083
There's only one caller of it and it's not sound: The runnable captures a
raw frame pointer etc. Instead, just do a dispatch to the main thread
and call OpenMenu there. This simplifies the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D131082
Otherwise the origin of the rect might not be correctly converted.
We have a supposed test for something like this:
layout/reftests/forms/input/number/spinner-overflow-vertical.html
But in practice it doesn't work, because I removed the "overflowing
descendants inflate outlines" behavior (bug 1739894), and even with that
pref it doesn't seem to cut it... So repurpose that test to test both.
Differential Revision: https://phabricator.services.mozilla.com/D131175
Annotating each test individually lets us avoid introducing new failing tests
while we go through the backlog of failing tests.
Depends on D129162
Differential Revision: https://phabricator.services.mozilla.com/D129163
Glenn Watson
Deian Stefan
Cristian Tuns
Andrew Osmond
Emilio Cobos Álvarez
Nika Layzell
criss
Mike Hommey
Butkovits Atila
Hiroyuki Ikezoe
lamoure6
Sylvestre Ledru
Sandor Molnar
Alexandru Michis
Ting-Yu Lin
sotaro
Niklas Goegge
André Bargull
Greg Tatum
Bob Owen
Andi-Bogdan Postelnicu